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]

2.3 branch status


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]