Re: versioning

[Roland McGrath <roland at redhat dot com>]

> I agree with these stability issues.  To have a stable version (ABI
> wise) every two weeks restrains us.
[...]
> That could be done, I agree.  We should put the date in the installed
> glibc, e.g. as above.  But what's the difference between a version
> number and a date in this regard?

The difference between a date and a version number is what convention
we associate with them.  Basically, the de facto convention is that
version numbers are associated with firm APIs and ABIs.  The reason I
suggested snapshot dates as a nomenclature is to have something that is
clearly not a deliberate stable point of API/ABI development.  That
makes quite distinct the meaning of the next assigned version number,
which can correspond to symbol version set names denoting newly-firmed
ABIs.  My motivation is to have agreement that is clear amongst
ourselves, and clear to users, when ABIs are firm and when they are
not.  I am open to whatever details get us there.

> What might work is a release branch.  I would make a branch point and
> port all bugfixes from mainline to this branch and then release a
> glibc version - let's say a few weeks (2-4) after the branch.  The
> next distributor would do the same at some point of time - and we
> might even see several release branches at one time :-(.

My suggestion about retroactively declaring releases from prior
snapshots was simply motivated by the idea of formalizing existing
communal practice.  I didn't suggest branches because we have not (as a
community project) been using them in a meaningful way before now.  I
think doing so might well be a mighty fine thing.  I am only looking
for whatever solutions will in fact be a useful formalization of how
people do now work, or would prefer to be able to work, together on glibc.

The reality is that each distribution maintainer does have a release
branch.  There is no shame in having several such release branches--if
they are actively maintained branches representing the releases major
distributions are actually using.  These forks exist already in the
world and in the daily work of the people who participate here in
communal glibc development.  Each distribution's glibc maintenance
operates similarly to what you described for SuSE.  Jakub does that for
Fedora/Red Hat.  Others on this list do the same for Debian.  This has
always been done separate from the community glibc source repository.
If those maintainers would like to use branches in the shared public
repository for this, I think that would be great.  Jakub maintains Red
Hat's branch of GCC this way, and that seems to be working out well.  I
think keeping the different branches in a shared repository is a great
way to facilitate everyone's tracking of development and maintenance.
I figure anything that streamlines the process of sharing code is a
boon to overall efficiency of maintenance.  But this can only be
worthwhile if the distribution maintainers want to do it.  I do not
speak for any of them.  If people don't want to do it, it's moot.

An important component of Ulrich's original notion was the need to
recognize the way glibc release, distribution, and maintenance is in
fact taking place.  We don't need bureaucracy to help the communal
effort catch up.  We need to start with the separate efforts that have
been doing the job in the real world, leverage those, formalize what
really does take place already, and collectively improve it from there.

There will probably always be differences between the glibc release
branches used by different distributions.  Each has its own
compatibility obligations, usage circumstances, and policy decisions
that may well never be agreed as appropriate for the official community
standard glibc code base.  That is fine.  What we are concerned with
here is that which can be shared.

An official release branch is only useful if the distribution
maintainers find it of practical aid to their productivity and
effectiveness.  It's not to anyone's benefit if maintaining the release
branch per se is an extra chore with no inherent utility.  If there are
multiple distribution release branches, then I would hope that it would
be natural and easy to maintain a communal release branch that contains
exactly the fixes that everyone is going to use in their own releases.
If the forks keep in synch this way so that when code is taken into a
branch, its text matches exactly with the shared release branch, the
diffs between a distribution's glibc and the canonical release branch
will be just the minimum that they have to be.  Then the tip of the
shared branch can be named an official release yielding canonical
tarball contents, and each different flavor of glibc source package
will need only that and a small distribution-specific amount of
patching.  I think it would be great to do this in the future.  But
there is no point in me specifying how it would be.  The distribution
maintainers have to say what they want to do.  I am eager to hear.

We have not really had "release freezes" (at least lately).  But there
are "quiet" periods where ABIs are not being perturbed and everyone is
focussed on stabilizing changes.  For example, since version.h was
bumped to 2.3.3, there were no ABI additions and there were lots of
necessary bug fixes in recent weeks.  Only in the last few days have
2.3.4 symbols been added.  Up until then, the trunk could have been
said to have been in release freeze for 2.3.3 (if we had such a formal
process, which we don't).  If we did make release branches, we might
not want to have made one before 2004-1-13 or so.  That is, the way
branches are done should follow what development is doing at any given
time, not try to be rigid.  OTOH, if we had a formal process of
freezing ABI changes to version sets, we'd better have done that
earlier, since OS distributions shipped with GLIBC_2.3.3 version sets
before then.  To me that emphasizes the need to better formalize what
is going on now, without trying to slow it down.

I've written a lot.  But I think we really just need to do a few
straightforward things to cooperate in a more efficient way that helps
all of our work.  If everyone is committed, I think making it happen
will come easily, and I look forward to facilitating that.


Thanks,
Roland