This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]