From: Evan Prodromou <evan@glug.org>
Subject: Re: Stable branch will freeze.
Date: Sat, 16 Mar 2002 12:12:05 -0600 [thread overview]
Message-ID: <87elik1ix6.fsf@tyrell.bad-people-of-the-future.san-francisco.ca.us> (raw)
In-Reply-To: <87vgbywwxp.fsf@zagadka.ping.de> (Marius Vollmer's message of "15 Mar 2002 00:29:06 +0100")
>>>>> "MV" == Marius Vollmer <mvo@zagadka.ping.de> writes:
MV> We need to be much more rigorous about really keeping the
MV> stable branch stable. From now on, only release critical,
MV> uncontroversial fixes will be allowed. I intend to be firm on
MV> this. We are not getting anywhere without restraining us from
MV> putting new stuff into the stable branch.
MV> Of course, it is already controversial exactly what is release
MV> critical. I'll just be deciding this. :)
So, ummm... I definitely agree that Guile 1.5.x is at a time when it's
really important to hit a release, and that feature enhancements need
to stop.
However, I kind of agree with Thi that there's some process that needs
some work here. I'd recommend that you maybe ask one of the people
who've been concentrating on this release to mark the BUGS file -- or
another file, or a daturbase or whatever -- with a criticality level.
Make sure that all important and reported bugs are in there, and that
all bugs are marked, and that *you* agree with the criticality.
Having a document means that everyone can see what needs to be worked
on, what hasn't been identified yet, etc. People can see the release
coming closer as the list of bugs in the document gets smaller. And,
finally, when the RC bugs in the list are gone, people have some
warm-fuzzy feelings that perhaps they haven't rushed the release out
the door.
SO, to reiterate: delegate bug-tracking duties to release managers,
and use a document to back up the tracking.
~ESP
--
Evan Prodromou
evan@glug.org
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel
next prev parent reply other threads:[~2002-03-16 18:12 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-14 23:29 Stable branch will freeze Marius Vollmer
2002-03-14 23:47 ` Neil Jerram
2002-03-15 0:02 ` Rob Browning
2002-03-15 19:38 ` Marius Vollmer
2002-03-15 0:02 ` Rob Browning
2002-03-15 0:05 ` Thien-Thi Nguyen
2002-03-15 9:24 ` Neil Jerram
2002-03-15 11:47 ` Thien-Thi Nguyen
2002-03-15 11:59 ` Thien-Thi Nguyen
[not found] ` <87adt9eq8e.fsf@raven.i.defaultvalue.org>
2002-04-03 3:20 ` Thien-Thi Nguyen
2002-04-03 4:22 ` Rob Browning
2002-03-15 19:54 ` Marius Vollmer
2002-03-15 23:19 ` Thien-Thi Nguyen
2002-03-16 0:08 ` Marius Vollmer
2002-03-16 0:39 ` Thien-Thi Nguyen
2002-03-16 18:12 ` Evan Prodromou [this message]
2002-03-18 20:19 ` Rob Browning
2002-03-20 21:53 ` Marius Vollmer
2002-04-03 3:33 ` Thien-Thi Nguyen
2002-04-03 4:25 ` Rob Browning
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=87elik1ix6.fsf@tyrell.bad-people-of-the-future.san-francisco.ca.us \
--to=evan@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).