On 02/09/2011 01:48 PM, Bernhard Reutner-Fischer wrote: > On Wed, Feb 09, 2011 at 01:38:00PM -0600, ANDY KENNEDY wrote: >>> -----Original Message----- >>> From: [email protected] [mailto:[email protected]] On >> Behalf Of Bernhard Reutner- >>> Fischer >>> Sent: Wednesday, February 09, 2011 1:33 PM >>> To: [email protected]; Rob Landley; [email protected] >>> Subject: Re: A modest proposal: call it 1.0 >>> Where '+' means ported, 'o' means TODO/needs verification >>> o mips >> >> I'm using NPTL on Mips, if you consider this verification, then you have >> it. > > i've updated the TODO file accordingly. >> >> I too support the bump to 1.0 -- why wait? > > why not wait. Remember that it's a version number, nothing more. See > TODO >
Do you mean "We've had meaningless release numbers for so long, why stop now?" The reason not to wait is that if we don't call the NPTL release be 1.0, after 5 years of development, we will never have a 1.0 release. If you're waiting for the todo list to run out, it's not going to happen. There will always be SOMETHING left to do. As for the "nothing more", it signals that it's ready for significant use and that people should give the thing a try. Linux Weekly News or H-online could probably be convinced to cover a 1.0 release of uClibc and do a comparison between eglibc and uClibc. They're much less likely to do so (and people are less likely to read it) for a 0.9.32 release. Remember that the project is still recovering from a multi-year development drought, and that the eglibc and klibc projects were launched because uClibc was not seen as a reasonable alternative to glibc so people created their own. (Yes, I asked.) The majority of your "needs verification" list boils down to "we can't have bugs in our 1.0 release". Um... that means we can't have a 1.0 release. A more charitable reading is "We have to do everything we can to make sure there are no bugs in our 1.0 release, if there are things left that we could do then it's not time for 1.0 yet", see "always going to be something left to do" above... When the Linux kernel had its 1.0 release in 1994, the project was a little over 3 years old. BusyBox (which is about as old as uClibc, maintained by the same set of people for the start of that, and hit its "you can build a usable system out of this" stage at about the same time) had its 1.0 release six years ago, and that was after more than a year of 1.0-pre and 1.0-rc releases. I believe getting our development process unblocked to the point where we could conceivably switch to time based releases (as the linux kernel, busybox, most distributions... pretty much everything interesting) has already done, is a milestone. The previous milestone (0.9.26, stuff now "just works" by default so we stop tracking a known-working application list) went by unremarked. No upcoming milestone is more significant than either of those, and if we _aren't_ already planning what to do next by the time we reach them something is wrong. Rob _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
