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] |
Hi folks. I meant to post more about the state of 2.3.x maintenance at least a week or two before now, but here we are. The branch is in pretty good shape it seems to me. I am contemplating making the 2.3.5 release pretty soon, perhaps this week. See this link: http://sources.redhat.com/bugzilla/showdependencytree.cgi?id=libc235 That is a tracking bug for changes I expect to have in the 2.3.5 release. It's not unlikely I missed some loose ends, but everything I currently plan to put in that release is now on the branch. If there are any more changes you think should be in the 2.3 branch, please pipe up now. The only other thing I have in mind is the dlclose fixes for the elf/unload3 bug from the trunk. Those are still getting more testing and debugging right now, but I intend to backport those fixes once they gel. DO NOT add dependencies to my tracker bug, PLEASE! I'll add them when I'm convinced of the need for the given change to be on the branch, but that's my call. If you think something should be on the branch, send email to the list and make sure your subject line is clear. But first, please remember the criteria for inclusion on the release branch: 1. Your issue must have a bugzilla report. If it doesn't already have one, file one before you ask about putting the change on the branch. At least for this round, I've decided not to make separate bugzilla report copies for bugs reported on the trunk and also fixed on the 2.3 branch. This is why you'll see several of the bugs on the libc235 dependency list in CLOSED state. For now, it seems like less hassle not to separate the bugzilla items into "fix on trunk" and "fix on branch" as two individual bug #s. I realize this makes it a little confusing for users to track the state of fixes, and the plan might change in the future. 2. Your issue must be resolved on the trunk already. I'm not going to consider any fixes for the 2.3 branch if the problem persists on the trunk. Note, just because it's resolved on the trunk doesn't mean that the other criteria in this list don't still apply--they do. But, we don't want any regressions from items missed on the trunk because they were fixed on the branch first. We also don't want the release branch to address an issue one way and have the trunk changes choose a different means. We'll let the trunk development settle on a desireable approach to a fix before we consider whether the release branch might need some differences in the backport of that fix. 3. You must already be using your code in production. This is the core requirement at the heart of this release process. By "in production", I don't mean necessarily that the code is in a released product. I mean: a. It's in a glibc variant based on the current glibc-2_3-branch code (not ancient 2.3.3+patches or whatnot, preferably not just 2.3.4 either). b. Your sources and binaries using the change are available publically. c. Those binaries are being run by actual users in beta test, or some significant QA testing is being done on them. d. You consider the code ready to ship the code in your production release (or have done so already). If it's not sufficiently stable and proven to inflict on your users, then it's not going on the stable release branch. Nothing goes on the branch for testing. You need to be satisfied already with the testing of that verbatim patch before I'll consider it for the branch. (I have and will violate this rule for some trivial cases like missing #include's that are obvious OK to add. But I won't for more complex build problems, including basically anything that touches makefiles or scripts.) The example "good citizen" is, of course, me, with my other hat on; Jakub and I maintain the stable glibc for Fedora, which you can see in fedora-2_3-branch. The glibc updates for Fedora Core 3 are coming from this branch, which closely tracks the main glibc-2_3-branch and is now carrying fairly minimal divergence from the vanilla code. fedora-2_3-branch has the current 2.3 code, plus the dlclose fix still needing more testing, and glibc rpms from that are in FC3 testing now. The dlclose fixes won't be ready for the 2.3 branch until we achieve confidence in them using that FC3 glibc update. 4. This should go without saying: of course, the changes must be covered by a copyright assignment already filed with the FSF. Something that deserves special mention is the GCC4 changes. I have not put any of these changes on the branch, and intend not to do so at least for the 2.3.5 release. The current branch code has good production testing, and AFAIK all the systems using it are based on GCC 3.4 (or 3.3). I want to get the 2.3.5 release made without any undue perturbations. I will make it clear in the release announcement that you cannot build 2.3.5 with development GCC (after all, no GCC 4 release exists yet). I anticipate there will be lots of annoying reports from people building the 2.3 branch code with new GCCs, especially after the real 4.0 release. I don't really see a bona fide reason for caring about this, since it's the stable production branch and stable production systems are using 3.4. But, I do anticipate being whined at more than enough to relent and put the minimal changes necessary for building with the latest GCC onto the branch. This won't happen for 2.3.5; I am aiming for a 2.3.6 release about a month after 2.3.5, to roughly coincide with the anticipated GCC 4.0 release date. This will include changes necessary to build with GCC 4.0, but only the minimal ones and probably not e.g. all the changes to eliminate new warnings. We can reasonably expect that there will also be some worthwhile bug fixes between now and then that will justify another bug-fix release beyond the GCC4 issues. Please reply quickly if you have any concerns about the 2.3.x releases. Thanks, Roland
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |