On Sunday 22 November 2009 07:02:33 Carmelo Amoroso wrote: > Rob Landley wrote: > [SNIP] > > > Currently, it's not clear _which_ branch a development release would come > > from, and thus what would be worth testing. The nptl branch? The > > inexplicable other development branch which NPTL still hasn't been merged > > into more than 3 years after the OLS presentation on NPTL for uClibc? > > The merge of these two branches has been "in progress" since Erik was > > maintainer, but I've never even seen an -rc containing NPTL code. > > Hi Rob, > > it happens periodically that you post your concerns > against the NPTL merge and so on,
Oddly enough, I keep raising the exact same concerns because they're still unresolved 3 years later. I'm still waiting for the existing issues from about 2005 to be either addressed or abandoned so we can move on. Specifically, I've been waiting for the unmerged out-of-tree work SJ Hill and Manuel Nova were doing to stop holding up releases to the point where developers walk away from the project. Here's a couple very very long threads about the topic from 2006: http://lists.uclibc.org/pipermail/uclibc/2006-March/035777.html http://lists.uclibc.org/pipermail/uclibc/2006-March/035873.html And of course they continue into following months... http://lists.uclibc.org/pipermail/uclibc/2006-April/035936.html This is essentially a follow-up to _those_threads_, three and a half years later. > and it is becoming to be a bit irritating, I'm sorry to say this. I find it a bit irritating that uClibc development has been essentially moribund for five years now. This project had eight releases in 2002 (0.9.09 through 0.9.16), seven in 2003 (0.9.17 through 0.9.24), two in 2004, one in 2005, and none at all in the whole year 2006. That was the point at which I started sending the maintainer cakes to commemorate the one year anniversary of the current stable release. If you ignore bugfix-only backports, I'm contemplating a third cake. In 3 years. Does this strike _anybody_ as a healthy development process? The eglibc project exists because uClibc wasn't cutting it for the embedded development community. (And klibc could have been a use case of uClibc, too.) I'm happy to do work and help out, if I can figure out _how_. I would _like_ to take a more active role in this project, but right now the big blocking issue is the NPTL merge. It was the big blocking issue in 2008. It was the big blocking issue in 2007. It was the big blocking issue in 2006. No release has ever been cut from the NPTL tree. Somehow, more code needs to be added to the NPTL tree before code can be taken _back_ out of the NPTL tree and merged into the uClibc-dev tree that releases have always been cut from. I've never understood why this is the case. > Steve, Khem, myself and recently Austin have done a lot of effort in this > direction (plus obviously Mike, Bernhard and other guys), but this is not > an easy job, and I guess a lot of us are busy with a lot of other jobs in > the linux world beside uClibc. > > For example, we @ST, are working to provide prelink feature into uClibc, > that is something I think being really important for embedded system where > performance and fast-boot are becoming to be a pressing needs... > and this task is consuming time that we cannot spend in the merge... so I > don't care about merge currently. Ok, so to confirm: merging the NPTL tree is blocking a new -dev release, but nobody is actually working on it, nor do they plan to do so in the forseeable future. It's not only _not_ your current development priority, but you "don't care" about it. Thanks for clearing that up. So there's not only no schedule for a new development release, there's no roadmap. > But let me say that, even not merged, the NPTL branch for those supported > archs, it's a reality, production ready, embedded C library (a lot of > really big ST customers in the Set-top-box world are already using uClibc > on sh4 using all the work we've done in this year). I don't care which tree the -dev tree is, but there needs to _be_ one. If you can't merge the two trees THEN KILL ONE. Either one. Make that branch read- only and cut an -rc from the other. (If there are regressions, people can report them against the -rc and we can fish patches out of the frozen tree.) Remember when the Linux kernel used to have long development cycles, and during the 2.5 development series Dave Jones took it upon himself to During the 2.5 development series, Dave Jones's job was porting patches from 2.4 to 2.5? Just keeping things reasonably in sync was somebody's full-time job? http://kerneltraffic.osmirror.nl/kernel-traffic/kt20020401_160.html#13 And how one of the goals of the new 2.6 development process was to _prevent_ the stable and unstable series from getting so out of sync that it caused that kind of issue? http://lwn.net/Articles/94386/ http://lwn.net/Articles/144281/ New development is done against what people _use_, and if that's -stable then you have -dj tree style forward porting issues. And if switching from -stable to -dev is a lot of work with little payoff then very little of your userbase will ever bother to test -dev. And once the -stale branch is out of date enough, instead of people using the release versions you'll have private in- house forks like Mike maintained for blackfin, the gentoo-embedded guys maintained, or like you ship to your own customers based on your nptl tree... I've linked to michlmayr's "time based release management" video several times: http://www.youtube.com/watch?v=RwpOxX_2Shw Here's a text article about it for those who won't bother to view the video: http://www.linux.com/archive/articles/114247 And really all he's saying, all I'm saying, all Linus was saying, is "Release Early, Release Often", which you wouldn't _think_ would be controversial in an open source project in 2009: http://firstmonday.org/htbin/cgiwrap/bin/ojs/index.php/fm/article/viewArticle/578/499 http://radio.weblogs.com/0103807/stories/2002/12/01/understandingTheImportanceOfReleaseEarlyReleaseOften.html > So, please, if you want to contribute to this project, please take actions > and send patches... Which actions? Which tree? I am not in a position to make architectural decisions for the project. I can't declare a direction for the project, and I can't assign a release schedule. I am not the maintainer. Remember when I tried to deal with "two instances of linuxthreads" issue a year ago and got significant pushback? http://lists.busybox.net/pipermail/uclibc/2008-September/041032.html The problems are architectural. The problems are decisions the _maintainer_ has to make. > but do not periodically complain against the work that > other guys are not doing, because they don't have enough free time. > > I'm sure you will understand my point. I have energy (the new convenience store that just opened a block away stocks my favorite orange mango passion fruit energy drinks), and I _make_ time when necessary. I also have a build system set up to compile equivalent versions of uClibc on a half-dozen different hardware targets, boot them under qemu, and run the result to do arbitrary scriptable things. I've got an 8-way server with 32 gigs of ram set up to do nightly builds of _all_ those targets against the nightly snapshots of linux, busybox, and uClibc. I haven't been paying much attention to the results (in the case of uClibc because I dunno what -dev tree to _test_, and the nightly snapshots have been segfaulting "hello world" on i686 for a month so that's obviously not the one anyone's paying attention to), but the infrastructure is there: http://impactlinux.com/code/firmware/downloads/snapshots/ As for testing _more_ stuff under uClibc once I've got base systems built, some people have built the whole of Gentoo (from scratch) under the resulting emulated development environment: http://impactlinux.com/hg/gfs Other people have taken my build system and extended it to cross compile additional packages, it's designed to make that reasonably easy too: http://repo.or.cz/w/qi-bootmenu-system.git I'd love to help you get a release out. When? How? What specifically is involved? I've submitted a couple random feature patches or bugfixes recently, and I have a few more sitting around I haven't even checked in to my own source control system because my pile is way too big for this package already: http://landley.net/hg/firmware/file/850da666acc6/sources/patches/ But me pushing patches upstream bears no discernable relatonship to me being able to drop those patches out of my source control system. I'm sorry that mentioning this frustrates you. Needing to mention it frustrates me. I'm aware that complaining about it isn't helping. How _do_ I help? The moral of today's thread is that "Wait for the NPTL guys to finish the merge" _ain't_it_. Rob PS. If you think I'm picking on uClibc, read "The patch penguin debate" here: http://lwn.net/2002/0131/kernel.php3 Since then, I've learned to spell "ridiculous", and Linus has learned to explain when he delegates to a "lieutenants" layer above maintainers without _telling_ anybody, and to use/write distributed source control systems. -- Latency is more important than throughput. It's that simple. - Linus Torvalds _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
