This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Help with 2.15.1 release.
- From: Carlos O'Donell <carlos at systemhalted dot org>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: Carlos O'Donell <carlos_odonell at mentor dot com>, libc-alpha <libc-alpha at sourceware dot org>,libc-ports at sourceware dot org, Chris Metcalf <cmetcalf at tilera dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>
- Date: Thu, 21 Jun 2012 13:14:24 -0400
- Subject: Re: Help with 2.15.1 release.
- References: <4FE32D83.1090909@mentor.com> <20120621170949.B73DE2C08C@topped-with-meat.com>
On 6/21/2012 1:09 PM, Roland McGrath wrote:
> It certainly was never the intent when we originally established the
> release branch and release manager scheme that the release manager would
> do the actual backporting work. In fact, I was explicit at the time
> that nobody should be doing things that way at all. The idea of the
> release branch is not just that it gets backports that "make sense".
> The idea is that the purpose of releases is to have system-builders use
> them in building packaged systems. Those folks usually apply various
> patches to their releases, including backports of trunk bug fixes that
> they've deemed worthwhile for the users of their stable system releases
> to have. In the original conception, the release branch was a place for
> backport patches that multiple system-builders were already using and
> agreed were a good fix. The release manager's role, then, is to collect
> candidate patches from people who are already using and testing them,
> verify that they are only backports consistent with the behavior of
> changes already on the trunk, judge that they are stable and noninvasive
> enough to to be appropriate for the particular release branch, and lead
> a consensus decision on when the branch has collected enough fixes that
> it's a good time to make a point release. This involves a lot of scut
> work fiddling bugzilla, juggling git stuff, coordinating with other
> hackers, making tarballs, sending announcements, etc., but not very much
> actual coding at all.
>
> IMHO, anyone who has marked a bug requesting a 2.15 backport and has not
> already done the backport, tested the code, exposed their users to it,
> and reported all those details, is not holding up their end and you as
> release manager should either harangue them or feel free to ignore them.
Thanks Roland. Yes I realized that the way I'd written up the policy
and the way I behaved had painted me into a corner.
Cheers,
Carlos.