Release process, 2.15 and 2.16

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Mon, 16 Jan 2012, Carlos O'Donell wrote:

> Team,
> 
> I'm still working on the glibc 2.15 release tarballs.
> 
> I'm reviewing a handful of testsuite cases that fail on x86, after which 
> I'll make the release.
> 
> I hope that the testsuite failures are simply a problem with my environment.
> 
> I expect the release tarballs to be up by the end of the week.

I don't think it makes sense to delay release tarballs indefinitely 
awaiting a resolution of test failures.  2.15 is tagged, it is what it is 
and the conclusion on those test failures cannot make any difference to 
what goes in the tarballs.  I think you should make and upload the 
tarballs now and go through the various steps for making announcements, 
updating websites etc. as described on 
<http://sourceware.org/glibc/wiki/Release>.

More generally there are several things that don't make sense (to me) with 
the present process and should be changed:

* As noted above, problems found after tagging should not delay the rest 
of the release process.

* The release manager should be the person doing the tagging so they get a 
release and branch in a state they find satisfactory rather than having to 
take it in whatever state it happened to be at a point determined 
independently of them.

* There should be an explicit stabilization period on master before 
tagging / branching, during which architecture maintainers are asked to 
ensure stability on their architectures and the release manager control 
what changes are considered appropriate to go in.

* If people do find test failures and aren't resolving them immediately, 
we have a bug tracker and mailing lists to facilitate resolving them 
collectively, and should use them.

I propose that we rework the release process on the basis of the release 
manager doing all the relevant steps on master and determining the timing.  
Comments?  If agreed I'll rework 
<http://sourceware.org/glibc/wiki/Release> accordingly.

Carlos, you were interested in doing 2.16 as well.  If you're still 
interested I think you should announce a timetable *now* (and finish the 
2.15 steps).  Based on what Roland said in 
<http://sourceware.org/ml/libc-alpha/2012-02/msg00134.html>, some time in 
April seems appropriate for the release.  You should set a planned release 
date, a planned branch date (maybe a week after the release if we keep 
following the practice of releasing from master then branching a bit after 
that), a date from which changes on master should be restricted to keep 
things stable and some guidelines about what is appropriate during that 
stabilization period.

I think it would also be appropriate for you *now* to do the pre-release 
step of regenerating libc.pot on master and (if there are new or changed 
messages; you'd need to check that) generating a snapshot and submitting 
that to the Translation Project (and of course documenting how that is 
done on the Release page for future reference).

-- 
Joseph S. Myers
joseph@codesourcery.com