From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Thien-Thi Nguyen Newsgroups: gmane.lisp.guile.devel Subject: Re: Release management - take 1 Date: Tue, 23 Apr 2002 22:56:56 -0700 Sender: guile-devel-admin@gnu.org Message-ID: References: <87it6tinwb.fsf@raven.i.defaultvalue.org> Reply-To: ttn@glug.org NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1019628434 8123 127.0.0.1 (24 Apr 2002 06:07:14 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 24 Apr 2002 06:07:14 +0000 (UTC) Cc: guile-devel@gnu.org Return-path: Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 170Fvt-00026u-00 for ; Wed, 24 Apr 2002 08:07:13 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 170Fvb-0008Lu-00; Wed, 24 Apr 2002 02:06:55 -0400 Original-Received: from ca-crlsbd-u5-c4a-a-172.crlsca.adelphia.net ([24.48.214.172] helo=giblet) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 170Fq0-00083x-00 for ; Wed, 24 Apr 2002 02:01:08 -0400 Original-Received: from ttn by giblet with local (Exim 3.33 #1 (Debian)) id 170Flw-0007Hx-00; Tue, 23 Apr 2002 22:56:56 -0700 Original-To: rlb@defaultvalue.org In-Reply-To: <87it6tinwb.fsf@raven.i.defaultvalue.org> (message from Rob Browning on Sun, 14 Apr 2002 23:31:00 -0500) Errors-To: guile-devel-admin@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.devel:486 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:486 From: Rob Browning 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