unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Rob Browning <rlb@defaultvalue.org>
Subject: 1.6 release -- where I'd like us to go from here.
Date: Sun, 14 Apr 2002 23:39:48 -0500	[thread overview]
Message-ID: <87g01xinhn.fsf@raven.i.defaultvalue.org> (raw)


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


             reply	other threads:[~2002-04-15  4:39 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-15  4:39 Rob Browning [this message]
2002-04-24  7:21 ` 1.6 release -- where I'd like us to go from here Thien-Thi Nguyen
2002-04-24 14:04   ` Rob Browning
2002-04-24 18:11     ` 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=87g01xinhn.fsf@raven.i.defaultvalue.org \
    --to=rlb@defaultvalue.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).