I've been working through the most recent beta releases of uClibc 2.2, awaiting the final release beast so that I could nail-down on that one and then go back to having my lovely, stable LEAF box and have it run for a year or two before I felt compelled to upgrade again.
Back a few releases on the 2.2 beta/RC tree, I recall seeing:
Changes between 2.2.0_b4 and 2.2.0_b5
initrd * switched to dash with echo and hetio patches
which to me seems a bit strange, changing the shell (if I read that correctly) well into a beta release cycle. But things went smoothly and I personally benefited from the 'echo' patch (I think).
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.
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?
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.
(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. :)
And again, thank you to everyone who contributes to, and participates with the development of LEAF. I STILL love it!
scott; canada
------------------------------------------------------- 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
