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
On Tue, 21 Feb 2012, Paul Eggert wrote:
> 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.
I was thinking of a week or two each release (with releases continuing to
be twice a year). Changes to be avoided in that period would probably be:
* Anything requiring ports architecture maintainers to update their ports
(the period should allow them to catch up with any updates left from the
previous development).
* Anything changing the public ABI and so requiring check-abi updates on
each architecture, or adding libm tests that will require ulps updates on
each architecture (again, the period allows for architecture maintainers
to update these files and get them ready for the release).
* Anything that subjectively seems too risky.
> 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.
I'd rather avoid needing too many changes (such as the architecture
maintainer catch-up mentioned above) needing to go in both places
simultaneously before the release.
It might make sense to have first stabilization and catchup on master,
then branch and have further stabilization before the release, but my
inclination would be that we should make the release point also the
branchpoint, and if someone doesn't think .0 releases are stable enough
then they can always wait for the .1 release from a branch.
--
Joseph S. Myers
joseph@codesourcery.com