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: 1.6 release -- where I'd like us to go from here. Date: Sun, 14 Apr 2002 23:39:48 -0500 Sender: guile-devel-admin@gnu.org Message-ID: <87g01xinhn.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 1018845732 10597 127.0.0.1 (15 Apr 2002 04:42:12 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 15 Apr 2002 04:42:12 +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 16wyJg-0002ko-00 for ; Mon, 15 Apr 2002 06:42:12 +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 16wyJZ-0000ps-00; Mon, 15 Apr 2002 00:42:05 -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 16wyHN-0000hr-00 for ; Mon, 15 Apr 2002 00:39:49 -0400 Original-Received: from raven.i.defaultvalue.org (raven.i.defaultvalue.org [192.168.1.7]) by defaultvalue.org (Postfix) with ESMTP id BBFE53F63 for ; Sun, 14 Apr 2002 23:39:48 -0500 (CDT) Original-Received: by raven.i.defaultvalue.org (Postfix, from userid 1000) id A317D2DCC; Sun, 14 Apr 2002 23:39:48 -0500 (CDT) Original-To: guile-devel@gnu.org Original-Lines: 81 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:384 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:384 For the duration of this message I'm just going to presume that no one was too scandalized by the "release process requirements" in my previous message and is mostly OK with the plan I outlined. If that's not true, then we'll have to revise the following accordingly. While it's too late for the 1.6 release to completely follow the plan I outlined, I'd like to propose that from this point forward, we proceed as if we *had* been following that plan, though I'd like to first review all the currently listed 1.6 critical bugs and TODO items. Once we've finished that, I'd like to suggest we immediately start following the release requirements and process I outlined. Before reviewing the release critical items, I'd like to (re)state right up front that I feel like 1.6 is such an improvement over 1.3.4 and 1.4 that even if we released guile in its current state, it would be a major improvement for most people. The good work everyone here has been doing really becomes obvious when you watch someone who's used to 1.3.4 or even 1.4 start messing with 1.5, see them look through the new documentation, etc. There are going to be migration problems, and other issues; I'm sure of that, but we can always follow 1.6.1 up with regular 1.6.X point releases to fix whatever we've missed, and we can improve our documentation and web info as needed to help people with the transition. Here are the things currently listed as holding up the 1.6 release: (1) bugs/optargs-bound-gone Marius: you discussed a fix for this in email, but also mention that it's functionality is fairly easily worked around via default value -- so are we fixing it for 1.6, or are we adding a NEWS entry recommending the alternative approach? (2) bugs/intructions-to-distributors [rlb] I'll handle this one -- I'll either have full fledged instructions by the release, or I'll include some information and a request for packagers to contact guile-devel before packaging. This will depend on how far I get before all the other release critical bugs are finished. (3) tasks/TODO - document libtool conventions [rlb] Needs to be done -- will do. (4) tasks/TODO - convert bug tracking/summarization process Is this really 1.6 release critical? It seems like it could be moved to a 1.8 section or "Eventually" to me, but I may be missing something. For 1.6, it seems like we can easily just create copy BUGS by hand if this is likely to hold things up any longer. (5) tasks/TODO - write build/bugs-triage.text - complete build/stability.text [ttn] - make sure all bugs have required headers Are these really 1.6 release critical? I'm inclined to want to move these to the 1.8 section as well. While I think these improvements are important, and should certainly be finished by 1.8, they don't seem like anything that can't wait until 1.6.2, etc. And what else is there? Please speak up if you can think of pre-1.6 issues that aren't addressed here so that we can evaluate them and add entries to TODO if appropriate. I'd like to discuss all these items and modify TODO and bugs/* according to our conclusions as soon as possible, but bear in mind that Thien-Thi likely won't be back until next week, and I don't want to be too gung-ho about any of this until he's had a chance to evaluate my two release propsals and express his concerns if any. Thanks again. -- 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