Re: Release process, 2.15 and 2.16

[Roland McGrath <roland at hack dot frob dot com>]

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

Conversely, I don't think it makes sense to declare and announce an
official release when we know it to be buggy.  IMHO there's no loss
if the next release is 2.15.1 and takes a few weeks more.

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

This is mostly an artifact of the previous procedure of tagging
quasi-randomly before addressing stability, which we should change anyway.
Certainly, nothing needs to delay the non-committal steps of the process.
But uploading a tarball and sending announcement email should not be done
when the new release has known regressions from the last release.

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

I tend to agree with these sentiments at the high level.
But we need much more discussion and agreed concrete process
to decide exactly how to work this.

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

Certainly.

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

This could be a reasonable start for the next cycle.  Obviously the next
cycle is going to be the first instance of the new ways of doing things and
thus a prototype for the cycles to come, and we'll hone the process in
successive cycles.  But I'd like it to be done in the context of setting
out the general formula for our schedules and procedures in the future.

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

Certainly this should be done.  The details of the preferred timing and so
forth should be worked out with the Translation Project on the basis of our
approximate twice-a-year schedule, and of course thoroughly documented.
The practice in many projects is to have a "string freeze" that is similar
to, but independent of other kinds of stabilization period.  This is the
time when you update .pot files and submit them to the translators.  That
is probably appropriate for us too, as is that it be earlier than the
release stabilization proper, to allow translation teams time to work
before the release.


Thanks,
Roland