This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Release process, 2.15 and 2.16
- From: Paul Eggert <eggert at cs dot ucla dot edu>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Carlos O'Donell <carlos_odonell at mentor dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Tue, 21 Feb 2012 10:05:23 -0800
- Subject: Re: Release process, 2.15 and 2.16
- References: <4F1433FE.1020308@mentor.com> <Pine.LNX.4.64.1202211336510.14244@digraph.polyomino.org.uk>
On 02/21/2012 05:58 AM, Joseph S. Myers wrote:
> * 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.
All these suggestions sound good, except I have a qualm about
the above step. Emacs does something similar, and its
explicit stabilization period typically stretches out for many
months. This hampers and discourages development.
Of course developers can continue to make changes in
private branches, or in a shared 'pending' branch, but in practice
Emacs's 'pending' branch is not much used (only two checkins in
the last six months) and developers are often inhibited from
making any improvements at all.
Stability is a vital goal, but it is not the only goal,
so I hope that any stabilization period on master
is kept short: a matter of days rather than months.
If more than a few days are needed to stabilize for a release,
it'd probably be better to stabilize in a branch
devoted to that release.