Release management - take 1

Release management - take 1

[Rob Browning]

(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

Re: Release management - take 1

[Thien-Thi Nguyen]

   From: Rob Browning <rlb@defaultvalue.org>
   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

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

Re: Release management - take 1

[Rob Browning]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

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

Sounds good.

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

Sounds reasonable -- I've actually had a few false starts on such a
script here -- initially for my own use, but if it ended up being good
enough I had planned to add it to guile.

I have to say, though that so far I've still been more comfortable
just having the RELEASE list and doing each step by hand, but I agree
that a *good* script would likely be a win, so I'll keep at it.

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

That's fine with me.  I'll make the change.  In truth, I expected
there to be some slack in there anyhow, but I wanted to make sure
things didn't drag out too long.  You're probably right, though, two
weeks is probably better, making sure at least two weekends are in
there for people who need to do the work then.

> everything else looks great.  i like being able to visualize code
> based on these descriptions...  now on to the unique process...

OK, I'll take my original and your comments and merge these into the
workbook.  I may also take your suggestion (in another message) and
make doing this be the resolution to one of the "release critical"
bugs, but I really don't think this should hold up the 1.6.1, since
everyone here involved knows what's going on.  Accordingly I'd like to
reserve the right to move the relevant todo item to being 1.8 release
critical if everything else is done, but let's see how far I get by
Monday.

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

Re: Release management - take 1

[Thien-Thi Nguyen]

   From: Rob Browning <rlb@defaultvalue.org>
   Date: Wed, 24 Apr 2002 08:39:07 -0500

   Sounds reasonable -- I've actually had a few false starts on such a
   script here -- initially for my own use, but if it ended up being
   good enough I had planned to add it to guile.

cool.

   I have to say, though that so far I've still been more comfortable
   just having the RELEASE list and doing each step by hand, but I agree
   that a *good* script would likely be a win, so I'll keep at it.

i'm in parallel writing such a dist-guile (based on dist-guile-www)
aimed for 1.4.1 release (so you see, i'm bugging you to write this stuff
down so that i can follow your lead).  it doesn't do all the things in
RELEASE, just the mechanical bits.  will probably checkin today.

   two weeks is probably better, making sure at least two weekends are
   in there for people who need to do the work then.

good point.  weekends are quite precious to volunteer efforts.

   OK, I'll take my original and your comments and merge these into the
   workbook.  I may also take your suggestion (in another message) and
   make doing this be the resolution to one of the "release critical"
   bugs, but I really don't think this should hold up the 1.6.1, since
   everyone here involved knows what's going on.

that's wishful thinking.  the day everyone knows what's going on, the
universe will blink out of existence.  remember that there are lurkers
(reading this) who may become guile maintainers in the future, and
indeed current maintainers (self included) who are depending on you to
do the thinking for them on these matters.

   Accordingly I'd like to reserve the right to move the relevant todo
   item to being 1.8 release critical if everything else is done, but
   let's see how far I get by Monday.

i'm glad to see checkins of process-related docs.

thi

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

Re: Release management - take 1

[Thien-Thi Nguyen]

   From: Thien-Thi Nguyen <ttn@giblet.glug.org>
   Date: Tue, 23 Apr 2002 22:56:56 -0700

   new TODO item: "write maintainer script dist-guile"

dist-guile now supports restarts:

# usage: dist-guile TAG [START]
#
# This must be run in a branched top-level guile-core dir (so
# that CVS/Tag looks something like: branch_release-X-Y).
#
# Description of each step:
#  0 - set vars and do other init
#  1 - check all files under cwd are unmodified (sync'ed w/ cvs repo)
#    - sh -x autogen.sh
#  2 - create distdir ../dist.$branch
#    - in $distdir do configure, make, make check
#  3 - in $distdir do make distcheck
#  4 - cvs tag TAG         (where TAG is $1)
#
# Optional arg START means start at that step (step 0 is always done).
# This is useful for avoiding long rebuilds after fixing minor mishaps.

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