From: Thien-Thi Nguyen <ttn@giblet.glug.org>
Cc: guile-devel@gnu.org
Subject: Re: Release management - take 1
Date: Tue, 23 Apr 2002 22:56:56 -0700 [thread overview]
Message-ID: <E170Flw-0007Hx-00@giblet> (raw)
In-Reply-To: <87it6tinwb.fsf@raven.i.defaultvalue.org> (message from Rob Browning on Sun, 14 Apr 2002 23:31:00 -0500)
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
next prev parent reply other threads:[~2002-04-24 5:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-15 4:31 Release management - take 1 Rob Browning
2002-04-24 5:56 ` Thien-Thi Nguyen [this message]
2002-04-24 13:39 ` Rob Browning
2002-04-24 17:17 ` Thien-Thi Nguyen
2002-05-14 10:59 ` Thien-Thi Nguyen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E170Flw-0007Hx-00@giblet \
--to=ttn@giblet.glug.org \
--cc=guile-devel@gnu.org \
--cc=ttn@glug.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).