From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Rob Browning Newsgroups: gmane.lisp.guile.devel Subject: Release management - take 1 Date: Sun, 14 Apr 2002 23:31:00 -0500 Sender: guile-devel-admin@gnu.org Message-ID: <87it6tinwb.fsf@raven.i.defaultvalue.org> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1018845200 10195 127.0.0.1 (15 Apr 2002 04:33:20 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 15 Apr 2002 04:33:20 +0000 (UTC) Return-path: Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16wyB5-0002eK-00 for ; Mon, 15 Apr 2002 06:33:19 +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 16wyAq-0000ND-00; Mon, 15 Apr 2002 00:33:04 -0400 Original-Received: from dsl-209-87-109-2.constant.com ([209.87.109.2] helo=defaultvalue.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16wy8r-0007cW-00 for ; Mon, 15 Apr 2002 00:31:02 -0400 Original-Received: from raven.i.defaultvalue.org (raven.i.defaultvalue.org [192.168.1.7]) by defaultvalue.org (Postfix) with ESMTP id 3563E3F63 for ; Sun, 14 Apr 2002 23:31:01 -0500 (CDT) Original-Received: by raven.i.defaultvalue.org (Postfix, from userid 1000) id 098C52DCC; Sun, 14 Apr 2002 23:31:00 -0500 (CDT) Original-To: guile-devel@gnu.org Original-Lines: 74 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.2 (i386-debian-linux-gnu) 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:383 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:383 (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