Martin, thanks for your thoughtful feedback.
Sorry about mis-appraising that the blank.gif issue was newly introduced.
For a suggestion in terms of Q&A, in a perfect world (I don't where to find it either, BTW) I imagine that one would embark on a new release with an idea of what one wanted to achieve. If a security bug were discovered part-way though that would warrant being added, on the fly, to the desired new-functionality-in-the-release but once, say, a 5-step beta was half-way though I would propose that new stuff try to to be added to the mix.
The way to achieve this would be, I guess, forks, akin to the way that Mozilla has done with the various milestones & branches. Obviously, however, there is none of the /huge/ base of developer manpower here nor the broad userbase nor the need (per corporate-product-embedders) that Mozilla has ... so the 'demand' would not seem to to merit the additional time & complexity on the part of developers - at least to the degree that Mozilla has done (including FireFox - 4 branches, as of July this year).
In a more practical sense, would it be feasible and not-too-time-consuming to maintain 2 branches of the BuC development - one that works on a 'stable' release base and one that works on bleeding-edge stuff, with the idea that some time in the near future the bleeding edge shall move to stable?
I've no idea about the demands that would place on others and would positively respect a decision as simple and terse as "yes, more work - not interested". (Not that I'm asking for a 'decision' - I guess that I've achieved something here by talking about it and becoming better informed myself, as would hopefully other readers).
Also, akin to what you pointed out - everyone (non-developer) may well just be using the 'stable' branch, thereby not giving the beta/bleeding-edge branch much of a workout so any bugs therein would not get noticed until they became a stable release anyway.
Again, thanks for sharing your side of the equation. I understand better, your/the-BuC-team's decisions.
And no, I've seen no open-toed shoes at all! I just wanted to be extra careful about 'complaining' about the decisions of others, others who devote orders-of-magnitude more time than I to this project and for whose efforts I am truly grateful.
My usual sign-off for posts here: Thanks for LEAF!
scott; canada
Martin Hejl wrote:
freeman groups wrote:
Then...
Changes between 2.2.0_rc1 and 2.2.0
weblet
* splitted weblet contents and sh-http server
which seems to have ended up with a couple of minor bustages - the missing blank.gif and the "text/html" issue?
Since I was the person "guilty" of that - can you show me the version of weblet that included "blank.gif"? As far as I can tell, this file has been missing forever, and it was noticed (or rather reported) shortly after the release of 2.2 - so that one didn't have anything to do with the split. You're right about text/html issue though.
Now I can't say that the weblet split was the cause of the subsequent bustages but just in general, would one normally make changes such as splitting a package, after much beta and RC, right before a final release? I tend to think that no, not normally.
Depends. In theory, the split was simply a packaging change - not a single line of code/config was changed (if I remember correctly). So, it was deemed worth the risk to go with that. That a file was lost during the packaging change was unfortunate, but sh*t happens ;-)
So I just wanted to posit that /my/ preference, in terms of a release moving through beta and into RC and finally full release status would be for it to settle, with as little feature _addition_ as possible, afore it becomes a formal release. Ideally a release would live as RCxx, become accepted then move to full release-grade with usually no changes made at all?
Feel free to propose a QA scheme for a release cycle. But with the given manpower, I'd guess it would simply mean longer timespans before new features can be released. QA (if properly done) takes time, and that time cannot be used for development. So unless there's a much larger userbase that's willing to test a beta release, I don't see a way to change that.
Yes, one could have thown in another release candidate instead of releasing 2.2 - but I doubt the error would have been found (since the people who are willing to work with a beta are often the ones who feel most comfortable on the console, as opposed to a web browser - which is, unfortunately, also the case for the core developers of Bering uClibc). Maybe that assessment of the LEAF user-base is wrong - I'd be happy to be corrected.
I favour the "release early, release often" approach. Yes, it means that bugs will slip through, but it also means that new features don't sit on the developer's harddrive, before the majority of users can use it. And it means that bugs are spotted more quickly, because more people test it.
The alternative (admittedly, taken to an extreme) would be to have a never ending beta phase (since there's _always_ a package that's updated, which would be nice to include into the release, or some change in a package, that will result in saving a few bytes or making it more modular).
I guess that milestone releases such as Eiger, Bering 1.0/1.2, etc, seemed to be so very well vetted that the recent intra-beta changes seem to be not in keeping with that tradition and (trying not to sound snotty about it all) I would say that right-before-release-changes have had the
somewhat predictable effect of having the full, final release - 2.2 - quickly discovered as having some avoidable bugs within.
Be assured, there are more bugs still to be found. No length of beta phase, or amount of release candidates will fix that. That doesn't mean that changing stuff at the last minute should become a standard procedure, but to be honest, I don't see weblet as a "critical component" of a router (critical in the context of providing routing functionality and security), so I can live with that change, even after the package turned out to still have bugs.
(FWIW it's not entirely easy for me to 'complain' about how the 2.2 release was 'administered' - since I'm a beneficiary of the donation of time that others have made. But I care about LEAF, and have proselytized widely about this product [and shall continue to do so!] and feel that this is one instance where things could have been done better ... so I'm speaking up. Confronting this nagging-in-my-mind issue is merely indicative of the fact that I care about this project.)
I apologise if any toes were stepped. :)
I hope it doesn't sound like I feel "stepped on my toes" - I just wanted to give you my point of view, that lead me to give the "weblet split" a go, for 2.2 - and why I feel that sometimes it's "ok"to change things even shortly before a release, even if that increases the chance to introduce new bugs (which will be fixed in subsequent releases/updated packages).
Martin
------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
