This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Pull request for new glibc-2.10-branch


  Hi!

On Fri, May 22, 2009 at 01:17:08PM -0700, Roland McGrath wrote:
> Ulrich doesn't deal with release branches, so don't expect any action from
> him on this.  This is an excellent time to restart discussions about a
> coherent community process for release branch management among the rest of us.
> So let's get that going right now!
> 
> I think a good starting place for discussion is the ideas summarized in:
> http://sourceware.org/ml/libc-alpha/2004-12/msg00063.html
> 
> If we can work out a collective procedure that really gets used going
> forward by you for opensuse and by Jakub for Fedora, that will be one
> huge step in the right direction (what we've failed to manage for years).

  I agree with the outline of what kind of changes are supposed to
appear in stable releases - no API/ABI changes, bugfixes only, only
patches cherry-picked from master, etc.

  However, I disagree with the requirements on the changes to be checked
in the stable branch. To me it seems they are awfully rigid and raise
the bar extremely high where manpower is OTOH sorely lacking.

  Also, unfortunately the current glibc releases are in fairly rough
state and especially the first ~month after the release, many bugs in
the new code pop up and get patched quickly, and getting these fixes
easily was my primary motivation for starting my branch. OTOH becoming
more rigid and careful about including patches as the branch ages is
common sense.

  My idea of the stable branch was to serve as a _convenience_ for
system integrators, rather than an obstacle. So, I'm not really happy
about putting rigid requirements on the changes (even as much as
requiring a bugzilla entry for each) - instead, I think that common
sense of the maintainers is much more effective way to manage the
branch. Will the system integrator be better off grabbing plain 2.10.1
or head of my branch? [Or - after it gets some real-world testing,
which should still be a requirement before tagging next version.]

  So - of course, mainly early on, mistakes will probably happen, but is
that better or worse than no stable series at all like the situation is
now (and probably unlikely to change otherwise)?

-- 
				Petr "Pasky" Baudis
The lyf so short, the craft so long to lerne. -- Chaucer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]