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] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |