glibc 2.3 stable branch

[Roland McGrath <roland at redhat dot com>]

There is a new branch called glibc-2_3-branch in the glibc CVS
repository.  The tag glibc-2_3-base marks the point it forked from
HEAD (and the branch hasn't had any commits of its own so far).  This
is now the stable production release branch.  I anticipate calling
2.3.4 released soon with perhaps no further changes.  But the new
branch is for 2.3.x, not just 2.3.4; 2.3.5 and future 2.3.x versions
will come from this branch.  After 2.3.4, these releases will contain
necessary fixes only, and follow strict rules, as I have mentioned in
the past and will detail below.

The trunk of the glibc CVS repository remains the place for primary
development.  As of now, the work done there is slated for future
2.4.x releases (whenever they may be); new ABI symbols added will be
in a GLIBC_2.4 version set.

In bugzilla there is now a "2.3.4" version available, and for the time
being that's what reports about the code in glibc-2_3-branch should use.

In the past, I have described on this mailing list my thoughts for how
a stable release process would go.  There was never a whole lot of
discussion on it, and as a result I remain convinced of the wisdom of
my original plan.  That's what we're doing now.  I'll summarize the
essential rules of the process, but for the complex rationalizations
you can look up my prior drivel.

The paramount rule of the stable branch is that everything that
happens there must be specifically approved by the branch's release
manager, who is me.  I intend to be merciless about enforcing these
rules I'm making up right now.  (Of course, I will violate them myself
for unspecified reasons at unspecified times, but that doesn't mean I
will violate them for you when you ask.)

The essential theory of the stable production branch is that it only
ever gets changes that have already been tested in production.

Every change must have an associated bugzilla number.  When the issue
has been fixed in the stable branch, the bugzilla report should not be
marked as closed until the issue is resolved in the trunk code as
well.  If an issue is addressed in the trunk first and a change is
being backported, a new bugzilla item should be filed under the stable
version (now 2.3.4) explaining the situation.

There are no ABI or API additions in the stable branch.  There will
never be a new version set called "GLIBC_2.3.something", GLIBC_2.3.4
is it.  The only kind of ABI change that might be considered is
something correcting broken compatibility with a past ABI to match the
actual ABI of the past.  Header file changes will be restricted to
necessary things like syntax fixes and harmless things like comment
changes or minute macro rearrangements, or changes that correct a
recent unintended incompatibility with the API of the past.

No changes will go directly onto the stable branch.  No changes will
be automatically backported from the trunk to the stable branch. 
(I will probably relax this for non-code changes, and I'm liable to
make occasional exceptions for minuscule and obviously correct fixes.)

A change goes in only after it has been tested in real-world
situations in someone's production version of the stable branch code.
i.e., some kind of test release, or rolling public development with a
lot of testers (such as Fedora development, aka Rawhide), with some
credible amount of QA work done somewhere.  These releases of modified
versions of the stable branch are what in reality get all the real
testing there is, so they are part of the criteria for including code
in the stable branch.  I don't just mean "my distro uses this patch
and we are happy".  For starters, I mean whole-system distributors'
system libraries that are having production binaries tested regularly,
that are based on the entire current glibc stable branch, and have
minimal divergence from the official stable branch code.  To my
knowledge, at the moment these criteria mean de facto just
fedora-branch.  That's not because Fedora is special, it's because
Fedora is trying hard to stay close to the current official code.  I
hope the glibc maintainers for other distribution projects will bring
their packages up to using the current stable glibc code, and get
involved directly in the stable branch maintenance.  Patches meeting
these criteria don't necessarily go in, of course.  They are also
subject to the release manager's discretion, and I may reject things
that are not critically important enough for the stable branch, or
that are not good enough or not appropriate for GNU software, even if
everyone's distribution is using them.


Note that I have not done any branching or tagging of the add-on ports
module in the glibc repository.  It's easy enough to do retroactively
if we decide that's what we want.  Off hand, I am expecting that the
working ports there (actually everything there but am33 is known to be
quite bit-rotted already) may keep up only with the stable branch for
quite some time, and that new contributed ports will usually want to
start out targetted for the current stable branch at whatever time
they go into the ports repository.  Hence the ports module may well
stay one step behind, with its trunk corresponding to the current
stable branch of the libc module.


If you have questions about this process, please send them to me and
I'll CC my response to the list if I think it will be useful (unless
you ask me not to, of course).



Thanks,
Roland