Re: glibc release branch procedures
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.
Reply to: