Re: versioning

[Andreas Jaeger <aj at suse dot de>]

Roland McGrath <roland@redhat.com> writes:

> I don't like this plan.  I would like to fully address all the concerns
> that motivated it, but I think we can find different and better ways to
> accomplish that.  I hope you will take the time to help me understand fully.
>
> It is indeed useful to have manually designated releases, "formal" releases
> if you like.  The reason that makes these desireable for any piece of
> software is that making such a release is the way that we, the maintainers,
> announce that the state of the code is "good and stable"--something people
> can expect to upgrade to without unknown new pain, and that they might want
> to upgrade to if they are going to put off the next upgrade for some period
> of time beyond when the very next usable thing can be had.  It is not
> really the case that the development code is "always good with rare, brief
> exceptions"--it is often a moving target for significant periods in the
> natural course of development and maintenance (a few weeks of regex
> instability here, a few weeks of dynamic linker instability there) and
> there is no reason it shouldn't be.  
>
> Moreover, in the case of glibc there is a more compelling reason to want
> clearly distinguished releases.  That is, these are the points of API/ABI
> stability.  There is no reason we should not add new symbols or new
> versions of existing symbols with the relative freedom that we do now.
> During the course of development, we may add a new interface and then
> decide to change its details a week or three later.  We have always made
> clear that new and changed interfaces are subject to continual change
> between releases.  It should remain so.  Bottom line, to me what a "formal"
> glibc release means is a closing of the given GLIBC_x.y.z version set and a
> promise to provide binary compatibility for correct programs built from
> that point forward.  I presume that the reasons why it's bad for us, the
> glibc maintainers, to potentially support a proliferation of symbol
> versions are obvious, both the technical ones (version name explosion
> slowing searches and inflating binaries, symbol table and text inflation
> adding overhead) and the practical ones (cruft in the sources, future
> maintenance burden of compatibility versions).
>
> For these reasons, I object to abandoning formal glibc releases.  

I agree with these stability issues.  To have a stable version (ABI
wise) every two weeks restrains us.

> Now I would like to explore the root issues that motivated Ulrich's plan.
>
> I quite agree that the old plan of making official test releases, waiting,
> and declaring them tested and good enough before each official release, is
> not working any more and has not been working well for quite some time.
> The situation for some time now has been that some given state of
> development from cvs is taken as the true basis for the whole-system
> distribution versions of glibc such as Debian's and Fedora/Red Hat's called
> 2.3.2-NN and so forth.  The given snapshot chosen by each distribution's
> glibc package maintainers is what actually receives a lot of testing and
> gets deployed.  Overall, this is a perfectly fine state of affairs and
> exactly the way we want to get leverage from distribution-specific efforts.
> The problem is that this has not been feeding back into the mainline
> development/release activities in any orderly or well-understood way.
>
>
> I think the situation we want is that a formal glibc release is a statement
> after the fact.  That is, when a given snapshot state has gotten good
> testing via its use in whole system distributions and been declared stable
> in practice, then we christen that state with a release number.  That
> should be a wholly painless and easy process for any authorized maintainer
> to do, i.e. running a script that goes quickly and maybe doing a GPG
> signature.  There is no reason this shouldn't happen frequently, at least a
> hell of a lot more frequently than glibc releases have been heretofore.

I see some practical problem with that.  What we at SuSE do is to take
the latest release or a CVS version, and use that as basis.  When we
get to a release of our distribution, we only add those patches from
CVS that we consider important, e.g. we might not add the latest new
feature since it's unstable but add all bug fixes.  So, our SuSE glibc
is basically the CVS snapshot of day X plus some of the later patches.
I have no problem calling the CVS snapshot a release but it might
contain known bugs.

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 :-(.

> What I would like to see is a regular system of snapshots.  This means that
> GLIBC_i.j.k.yyyymmdd means exactly the same set of sources to everyone.

That's a good idea.  We enhanced our glibc already so that it reports
a day:
$ /lib/libc.so.6 
GNU C Library stable release version 2.3.2 (20030827), by Roland McGrath et al.
[...]

> (That's easy to do with tags or just with a clear specification of 0:00 UTC
> on each YYYY/MM/DD as the moment of repository state we're referring to.)
> tarballs (whether with or without CVS/ subdirs) are useful for some people,
> and it's not hard to make them available automatically, so we should do so.
> It is my hope that the glibc packages in development versions of each
> distribution can be based on canonical dated snapshots with vastly smaller
> numbers of additional distribution-specific patches than what we see now.

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?

> I would like to do whatever needs to be done to make the physical details
> of cutting a release as trivial and painless as possible.  None of this
> automation should be at all hard.  (We can start with dumping the "make dist"
> cruft and using simple scripts around cvs operations to make tarballs.)
> Whenever there is consensus that GLIBC_i.j.k.yyyymmdd is a stable point,
> it can be retroactively declared GLIBC_i.j.(k+1), diddled, tagged, and
> released with the push of a button.

Again we have a ABI stability issue here.  If a version is declared
stable after some weeks, we might have changed the ABI...

> If there are root motivations other than the ones that I have raised,
> please describe them explicitly.  Once I'm sure that all these are on the
> table, I would be happy to discuss how the suggestions I have made here do
> or don't address all the important issues.

Thanks for your suggestions!

Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SuSE Linux AG, Deutschherrnstr. 15-19, 90429 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

Attachment: pgp00000.pgp
Description: PGP signature