Re: Release process, 2.15 and 2.16

[Aurelien Jarno <aurelien at aurel32 dot net>]

Le 21/02/2012 14:58, Joseph S. Myers a écrit :
> 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.

If the period is not to short enough (let's say at least two weeks), and
is announced a bit before so I can organize myself, I can probably do
tests build and testsuite checks on the architectures that are supported
by Debian. Basically what I am doing now, except it's better to do this
job before the release than after.

> 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).

The proposed release process seems a lot better to what we have seen so
far for glibc. About the schedule it's always something difficult to
plan, so let's try to just make something reasonable, and then learn
from what has been done for the next release.

I really appreciate your investment on improving the development and
release processes of the glibc. It's very nice to see the things are
changing in the positive direction. Big thanks.

-- 
Aurelien Jarno                          GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net