Release management - take 1

[Rob Browning <rlb@defaultvalue.org>]

(What follows is my position with respect to the release process.
 I'll be speaking primarily here in my role as the Guile Release
 Manager, and I'll be commenting mostly on general release issues.
 Later I'll follow up with a second message speaking specifically
 about the 1.6 release, which is IMO (hopefully) somewhat unique.)

First, I feel like the release manager and the release management
process should always try to be more a help than a hindrance, but in
order to be able to make sure that we have quality releases, and that
we get them out the door in a reasonable amount of time, the release
manager will have to have *some* authority with respect to certain
issues.  Second, I feel like the *less* process we can have, the
better -- to paraphrase a famous quote -- "as simple as possible, but
no simpler".  I think we should start small and rework our process as
needed, based on actual experience.  No one is going to be able to
dream up the perfect system for this a-priori.

All that said, here is the set of requirements I've come up with
regarding releases:

   * The release manager will provide input to help decide when it
     might be time to branch for a release.  (Now that we have a more
     sophisticated bug tagging system, we won't normally branch until
     until all currently known release-critical issues have been
     resolved.  This should help limit the time between branch and
     release, which is in general a good idea.)

   * The release manager will handle creating the stable branch when
     appropriate.

   * 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.

   * No one should add entries to the TODO section for a branched
     stable release target, nor add/delete the corresponding bugs/*
     release-critical tags without the approval of the release
     manager.  Note that once we get to the point where we branch much
     more closely to the stable release, this shouldn't be a big
     issue.

   * 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.

   * 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.  If
     release-critical issues do arise, then at the release manager's
     discretion, fixing them may or may not require another beta
     pre-release (i.e. an endian fix might, but a minor documentation
     fix probably wouldn't).

   * The release manager will build, upload, and announce the stable
     release and manage future stable point releases.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel