[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Release management - take 1
Release management - take 1
Sun, 14 Apr 2002 23:31:00 -0500
Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.2 (i386-debian-linux-gnu)
(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
* 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
* 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
* 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.
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD
- Release management - take 1,
Rob Browning <=