On Thursday 10 December 2009 18:01:04 Joseph S. Myers wrote: > On Thu, 10 Dec 2009, Rob Landley wrote: > > On Thursday 10 December 2009 17:43:51 Joseph S. Myers wrote: > > > On Thu, 10 Dec 2009, Rob Landley wrote: > > > > > It's > > > > > LGPLv2.1 (or greater, so if you want to distribute pieces under > > > > > LGPLv3 you can), like FSF GLIBC. What happens if FSF GLIBC changes > > > > > license is up to the EGLIBC Consortium. > > > > > > > > EGLIBC FAQ #1: eglibc is not meant to be a fork. > > > > > > If FSF GLIBC were to change license, the Consortium would of course > > > need to consider whether they find the new license viable for embedded > > > use (and thus whether it would be necessary to become a permanent fork > > > off the last version with the old license). > > > > Where are your release versions? > > There are release branches corresponding to each FSF GLIBC release branch, > but no actual releases from them.
Oh dear. > These should be as stable (both in > general stability and in ABI terms) as the underlying FSF GLIBC release > branches; So are you claiming that you never make any changes, that your changes never break anything (or have unintended side effects in any configuration), or that glibc is such crap that adding "changeset du jour" on top can't possibly make it any worse? Releases aren't expected to be bug-free, they're a _known_ set of bugs. They give people a common frame of reference to compare notes with other people using it when person X is seeing a problem that Person Y is not. (They also give you a frame of reference to _discuss_ issues. "It didn't happen in .3") The linux kernel has fourth level dot-releases for the bugfix-only changes instead of just opening a git branch and telling people to pull at random. I suspect there's a reason for this. > snapshots from release branches have worked fine for Debian and > Ubuntu, for example. I.E. Organizations with their own full-time developer team, testing infrastructure, and release stabilization process can cope, why can't you? > If there's sufficient user demand for releases, the > possibility could of course be considered. Wake me if that happens. My interest has gone away again... Rob -- Latency is more important than throughput. It's that simple. - Linus Torvalds _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
