This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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. 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. 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 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. 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. 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, Roland
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |