[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Release management - take 1
From: |
Thien-Thi Nguyen |
Subject: |
Re: Release management - take 1 |
Date: |
Tue, 23 Apr 2002 22:56:56 -0700 |
From: Rob Browning <address@hidden>
Date: Sun, 14 Apr 2002 23:31:00 -0500
Later I'll follow up with a second message speaking specifically
about the 1.6 release, which is IMO (hopefully) somewhat unique.
bonus: ability to compare this unique process to the general process.
unique process features that might be required in the future indicate
where the hooks should go in the general process.
* Once a release branch has been made, no one should check in
changes to that branch without approval from the release manager
unless those fixes are for release critical bugs that they're
supposed to be fixing -- "supposed to" be means that the release
manager already knows about what they're doing, and "approval"
doesn't have to be all that formal. For example, popping up on
irc, talking to the release manager and then posting to
guile-devel that you're fixing "XZY" in the stable branch after
consultation on IRC with the release manager, is just fine.
* Eventually workbook/tasks/TODO and a scan of workbook/bugs/* for
the relevant release-critical tags should always provide a
*complete* picture of what's holding up a release. For those
that don't have direct CVS access, please make sure you ask
someone who does to edit TODO or bugs/* accordingly.
this latter point can be codified, and thus indicates a TODO item:
"write why-not-release? scanner" (just added).
* whenever all the currently listed release TODO items and release
critical bugs have been resolved (by whatever means), the release
manager will build, upload and announce a pre-release beta.
new TODO item: "write maintainer script dist-guile"
* If after a pre-release beta has been out for a week and no new
agreed-upon release-critical issues arise, the release manager
will build, upload, and announce the stable release.
i would up this to two weeks given how time flies when you get old
(maybe you are lucky to not feel this :-) and how we would like to
eventually encourage all people to participate, no matter age or other
business.
everything else looks great. i like being able to visualize code based
on these descriptions... now on to the unique process...
thi