This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc release branch procedures
- From: "Carlos O'Donell" <carlos at systemhalted dot org>
- To: Roland McGrath <roland at redhat dot com>
- Cc: Petr Baudis <pasky at suse dot cz>, jakub at redhat dot com, vapier at gentoo dot org, debian-glibc at lists dot debian dot org, allan at archlinux dot org, joseph at codesourcery dot com, libc-alpha at sourceware dot org
- Date: Sat, 20 Jun 2009 22:46:44 -0400
- Subject: Re: glibc release branch procedures
- References: <20090522033213.GJ14609@machine.or.cz> <20090522201709.03DD7FC35D@magilla.sf.frob.com> <20090523014222.GH6058@machine.or.cz> <20090523042552.3D63DFC35D@magilla.sf.frob.com> <20090524114440.GL14609@machine.or.cz> <20090604031830.4192BFC3C3@magilla.sf.frob.com>
On Wed, Jun 3, 2009 at 11:18 PM, Roland McGrath<roland@redhat.com> wrote:
> I propose these as recommended guidelines for all release branch managers:
>
> 1. Don't talk about recommended guidelines for all release branch managers.
> ? No, wait, do talk about them.
> ? Don't suspect your neighbor. ?Discuss him on libc-alpha.
> 2. Remember GNU copyright discipline, even for private branches.
> 3. Use git branch "release/x.y/master" as "the usual place to look"
> ? (whatever that means in your process). ?The x.y release manager
> ? should choose and specify conventions for "release/x.y/*" branches.
> 4. When a commit backports a change from the trunk (or another proper
> ? release branch), use "git cherry-pick -x" or otherwise clearly indicate
> ? the original commit id in the backport commit's log entry, and
> ? always aim for one separate backport commit per corresponding trunk commit.
> 5. When a commit is not a backport of a clearly identifiable single
> ? commit from the trunk or another release branch, then there should
> ? be some voluminous controversy or communal agonized consternation
> ? on the mailing lists about whatever it is. ?i.e., this should always
> ? be an automatic red flag for a release manager and all participants,
> ? so that it merits explicit discussion more than the usual routine.
> 6. Try to pay attention to what your past (or concurrent) predecessor
> ? release managers have done, and learn from their examples and mistakes.
> 7. Do not taunt Happy Fun Drepper.
>
> Too strict for you?
No. I think they are exactly what I would have suggested. You mention
it earlier in your email, but it should be made a separate point.
8. The release manager has veto.
Enshrined in our fast growing GlibcGit wiki page.
http://sourceware.org/glibc/wiki/GlibcGit
Cheers,
Carlos.