From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2804 invoked by alias); 7 Dec 2003 10:47:14 -0000 Mailing-List: contact libc-hacker-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-hacker-owner@sources.redhat.com Received: (qmail 2788 invoked from network); 7 Dec 2003 10:47:14 -0000 Received: from unknown (HELO Cantor.suse.de) (195.135.220.2) by sources.redhat.com with SMTP; 7 Dec 2003 10:47:14 -0000 Received: from Hermes.suse.de (Hermes.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id C154D18B426E; Sun, 7 Dec 2003 11:47:13 +0100 (CET) Received: from aj by arthur.inka.de with local (Exim 4.22) id 1ASwKl-0008Ac-Tp; Sun, 07 Dec 2003 11:40:15 +0100 To: Roland McGrath Cc: Ulrich Drepper , Glibc hackers Subject: Re: versioning References: <200312030119.hB31JSJ8008447@magilla.sf.frob.com> From: Andreas Jaeger Date: Sun, 07 Dec 2003 10:47:00 -0000 In-Reply-To: <200312030119.hB31JSJ8008447@magilla.sf.frob.com> (Roland McGrath's message of "Tue, 2 Dec 2003 17:19:28 -0800") Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) XEmacs/21.4 (Rational FORTRAN, linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-SW-Source: 2003-12/txt/msg00033.txt.bz2 --=-=-= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-length: 7093 Roland McGrath 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 ful= ly. > > It is indeed useful to have manually designated releases, "formal" releas= es > 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 maintainer= s, > 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 wa= nt > to upgrade to if they are going to put off the next upgrade for some peri= od > 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.=20=20 > > 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 "forma= l" > 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.=20=20 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 call= ed > 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 effort= s. > 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 stateme= nt > 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 th= at > 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=20 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 U= TC > 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 peopl= e, > and it's not hard to make them available automatically, so we should do s= o. > 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 d= ist" > 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 --=20 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj SuSE Linux AG, Deutschherrnstr. 15-19, 90429 N=FCrnberg, Germany GPG fingerprint =3D 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 --=-=-= Content-Type: application/pgp-signature Content-length: 188 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQA/0wOPOJpWPMJyoSYRAgMJAKCQ4+ATLYfZBtGOuj8UpLmXMp2+OwCbB5ax CMxNrF79s5Nue0AS7nQklx4= =EgUT -----END PGP SIGNATURE----- --=-=-=--