Re: Release management - take 1

[Thien-Thi Nguyen]

   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