glibc release management

[Roland McGrath <roland at frob dot com>]

You will get no argument from me about shorter release cycles, but I am not
someone doing much of the work.  There are many details to bicker about,
but I'm sure that the crux of Ulrich's reply will also be simply about the
time he has available to put into libc.  

There are multiple employees of all the major distributors on this list,
and it is well past time for those monied companies to put some serious
investment explicitly into glibc maintenance and development.  Those of you
working for distributors, I don't know how much of your paid job is
supposed to have to do with glibc, but as far as I am aware there is no
company paying anyone explicitly to work on the libc team per se (as
opposed to their distribution's modified glibc package).

We can have more frequent releases, and better release management, but we
cannot get it with Ulrich in charge of it alone unless that becomes his
sole paid job (and I am presuming he would rather keep doing other things
for Cygnus/Redhat instead of just glibc).  What we got now from Ulrich is
far better than one could presume to expect from anyone without paying to
have it be job 1.  Anyone complaining, complain to your boss or your boss's
boss and don't come back here complaining until your company is paying
someone (or better, part of a multi-company detente that pays someone) to be
distribution-independent GNU libc maintainer/release-manager full time.

On the pseudotechnical front, what I would like see is the "bug-fix"
releases made much more frequently and conservatively (i.e. totally binary
compatibility with no qualifications, no new features at all, etc), these
can be 2.1.x and we can get to 2.1.937 for all it matters, and would be the
only thing on the "stable branch" of the repository.  The mainline
development version (trunk in the repository) can add features and do
reorganizations, but still do releases fairly often (2.2.x, and not be
hesitant about this x getting large too), and reasonably have both stable
and current branches going and widely used for a good while.  Major
many-month rewrites such as the new locale implementation can be their own
branch off the trunk, updated from the trunk as needed by the person
hacking that branch, and pieces merged into the trunk from there as they
become a little less volatile; other people interested in tracking the
highly volatile new implementation on the branch can track that version
too, but when it's close to working and not changing incompatibly every
other day or being wholly restructured internally every week, it can get
merged into the "unstable" mainline.

But these details of organization will get figured out easily enough
when there are enough serious resources (paid hacker time) devoted to 
getting libc done right.  Considering the current amount of support (such as I
understand it), we are doing pretty damn well already.