public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Steven Bosscher <stevenb@suse.de>
To: gcc@gcc.gnu.org
Cc: Gerald Pfeifer <gerald@pfeifer.com>,
	Mark Mitchell <mark@codesourcery.com>,
	Benjamin Kosnik <bkoz@redhat.com>
Subject: Re: Revised release criteria for GCC 4.0
Date: Wed, 15 Dec 2004 01:45:00 -0000	[thread overview]
Message-ID: <200412150246.48746.stevenb@suse.de> (raw)
In-Reply-To: <Pine.BSF.4.61.0412142130040.91432@acrux.dbai.tuwien.ac.at>

On Tuesday 14 December 2004 21:33, Gerald Pfeifer wrote:
> On Tue, 14 Dec 2004, Steven Bosscher wrote:
> > In fact I think that getting release criteria so late in stage 3
> > is just silly and quite pointless
>
> Since the 4.0 release criteria shall serve as a template for the 4.1
> release criteria, I beg to disagree.

My "pointless" remark may be too strong.  When you have to deriving
release criteria based on an existing baseline (like, when you're in
stage 3 already) I guess there is not much more you can do.  Let me
say I'm quite happy that the secondary and primary platforms have been
updated.

Still, for the upcoming releases we should set goals for the releases
early on.  I realize this is hard.  But people rely on the judgment of
the RM and the SC.  If the release criteria for GCC 4.0 are a template
for GCC 4.1, I suppose our users should not expect too much of GCC 4.1.


> > especially now that they are in such a weak form and not very specific.
>
> In that past, we had much stronger criteria but basically ignored them.

I hope that the RM would just say "No!" to patches that don't satisfy
the release requirements for GCC 4.1.  If the release requirements are
set early enough to, say, judge on a branch being merged or not, it is
my opinion that the RM should have the power to say "No" to a branch
merge when mainline after the branch merge does not satisfy the release
criteria.  This was not possible in the past because release criteria
often were not available until very late in the release cycle.  When
the release criteria do not include performance (compile time and code
quality) requirements, the RM is left without power and I think we all
lose in the end.

Gr.
Steven

  reply	other threads:[~2004-12-15  1:45 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-13 23:50 Benjamin Kosnik
2004-12-14  0:04 ` Mark Mitchell
2004-12-14  0:20   ` Steven Bosscher
2004-12-14  0:26     ` Mark Mitchell
2004-12-14 20:33     ` Gerald Pfeifer
2004-12-15  1:45       ` Steven Bosscher [this message]
     [not found] <200501012127.43165.bjoern.m.haase@web.de>
2005-01-01 21:11 ` Björn Haase
  -- strict thread matches above, loose matches on Subject: below --
2004-12-15 14:43 Ed Smith-Rowland
2004-12-13 22:47 Daniel Kegel
2004-12-13 22:52 ` E. Weddington
2004-12-14  5:28   ` Ralf Corsepius
2004-12-14  5:39     ` E. Weddington
2004-12-13 14:41 Paul Schlie
2004-12-13 16:12 ` Bernardo Innocenti
2004-12-13 16:45   ` Peter Barada
2004-12-13 17:44     ` Paul Schlie
2004-12-14  7:29       ` Mark Mitchell
2004-12-13 18:26     ` Bernardo Innocenti
2004-12-13 18:40       ` Joe Buck
2004-12-14  0:49         ` Peter Barada
2004-12-14  0:54           ` Daniel Kegel
2004-12-14  1:29             ` Mark Mitchell
2004-12-14  0:44       ` Peter Barada
2004-12-15 15:00   ` Hans-Peter Nilsson
2004-12-15 17:14     ` E. Weddington
2004-12-15 18:37       ` Ian Lance Taylor
2004-12-15 19:22         ` E. Weddington
2004-12-15 19:48           ` Ian Lance Taylor
2004-12-15 21:58           ` Hans-Peter Nilsson
2004-12-15 21:58     ` Bernardo Innocenti
2004-12-15 22:16     ` Bernardo Innocenti
2004-12-13  2:09 Mark Mitchell
2004-12-13 12:38 ` Richard Earnshaw
2004-12-13 15:24   ` Mark Mitchell
2004-12-13 15:33     ` Richard Earnshaw
2004-12-15 16:17 ` Scott Robert Ladd
2004-12-15 16:44   ` Giovanni Bajo
2004-12-15 20:05     ` Mark Mitchell

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200412150246.48746.stevenb@suse.de \
    --to=stevenb@suse.de \
    --cc=bkoz@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=gerald@pfeifer.com \
    --cc=mark@codesourcery.com \
    /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).