freeman groups wrote:
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.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?
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 theBe 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.
somewhat predictable effect of having the full, final release - 2.2 - quickly discovered as having some avoidable bugs within.
(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 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).
I apologise if any toes were stepped. :)
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
