On Wed, Jun 3, 2009 at 11:18 PM, Roland McGrath<[email protected]> 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. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
