bugs in malloc

Rob Landley rob at landley.net
Fri Dec 11 00:40:41 UTC 2009


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


More information about the uClibc mailing list