public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Re:  Ada policy (was: GCC 3.5 Status (2004-08-29))
@ 2004-08-30 20:47 Richard Kenner
  2004-08-30 21:30 ` Laurent GUERBY
  0 siblings, 1 reply; 4+ messages in thread
From: Richard Kenner @ 2004-08-30 20:47 UTC (permalink / raw)
  To: laurent; +Cc: gcc

    The scenario I want to avoid is that we first reach 100% ACATS pass on
    the two targets (looks likely), then later a patch goes in that
    introduces 20 ACATS regressions on those two targets and the patch is
    not fixed or reverted following the usual rules for other components. 

Yes, but that's a *different* standard.  What you are talking about
if whether the commit rules will require running ACATS to commit a
patch.  The question raised was whether Ada should be part of the
release criteria.

These are not the same.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re:  Ada policy (was: GCC 3.5 Status (2004-08-29))
  2004-08-30 20:47 Ada policy (was: GCC 3.5 Status (2004-08-29)) Richard Kenner
@ 2004-08-30 21:30 ` Laurent GUERBY
  2004-08-31  9:41   ` Release criteria (was: Ada policy) Gerald Pfeifer
  0 siblings, 1 reply; 4+ messages in thread
From: Laurent GUERBY @ 2004-08-30 21:30 UTC (permalink / raw)
  To: Richard Kenner; +Cc: gcc

On Mon, 2004-08-30 at 22:28, Richard Kenner wrote:
>     The scenario I want to avoid is that we first reach 100% ACATS pass on
>     the two targets (looks likely), then later a patch goes in that
>     introduces 20 ACATS regressions on those two targets and the patch is
>     not fixed or reverted following the usual rules for other components. 
> 
> Yes, but that's a *different* standard.  What you are talking about
> if whether the commit rules will require running ACATS to commit a
> patch.  

Sorry I wasn't clear on my intent. The commit rules don't require you to
test on all the platforms, but if someone report that you break one you
didn't test, it's still considered your fault and you should try to help
on the issue, and in some extreme cases the patch could be reverted (at
least that's my understanding).

This "platform" rule could also be applied to components, you don't
necessarily have to test Ada, but if someones points out
a breakage, you have to be helpful on the issue.

(BTW I didn't find on the web site a link to the 3.4 release criteria
page http://gcc.gnu.org/gcc-3.4/criteria.html, and didn't find one for
3.5 did I miss something?)

> The question raised was whether Ada should be part of the
> release criteria.
> 
> These are not the same.

May be but I must admit I fail to see the practical difference, if
you're not continuously looking in some way at regressions on one
platform or component for a full development cycle, it's unlikely that
you'll be able to reach any relase criteria involving this platform or
component at the end of the cycle (without potential delays).

The current rules differ on who should be "looking" at regressions
depending on component vs platform (the patch submitter or someone
else), but that's less important IMHO than having a consistent rule on
what to do when a regression is detected on a particular patch.

Laurent


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Release criteria (was: Ada policy)
  2004-08-30 21:30 ` Laurent GUERBY
@ 2004-08-31  9:41   ` Gerald Pfeifer
  2004-08-31 13:29     ` Release criteria Robert Dewar
  0 siblings, 1 reply; 4+ messages in thread
From: Gerald Pfeifer @ 2004-08-31  9:41 UTC (permalink / raw)
  To: Mark Mitchell; +Cc: Laurent GUERBY, Richard Kenner, gcc

On Mon, 30 Aug 2004, Laurent GUERBY wrote:
> (BTW I didn't find on the web site a link to the 3.4 release criteria
> page http://gcc.gnu.org/gcc-3.4/criteria.html, and didn't find one for
> 3.5 did I miss something?)

We started with very detailed (and agressive) release criteria for 3.0,
but somehow this didn't really work out, neither for 3.0 nor for later
releases, mostly due to the volunteer nature of the GCC project.

So I guess the closest thing we have these days is Mark's mental picture
of Bugzilla and open projects and the status mails he is sending.  I'm not
really sure how to formalize and write this down as a release criteria
documents.

Gerald

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Release criteria
  2004-08-31  9:41   ` Release criteria (was: Ada policy) Gerald Pfeifer
@ 2004-08-31 13:29     ` Robert Dewar
  0 siblings, 0 replies; 4+ messages in thread
From: Robert Dewar @ 2004-08-31 13:29 UTC (permalink / raw)
  To: Gerald Pfeifer; +Cc: Mark Mitchell, Laurent GUERBY, Richard Kenner, gcc

Gerald Pfeifer wrote:
> On Mon, 30 Aug 2004, Laurent GUERBY wrote:

> So I guess the closest thing we have these days is Mark's mental picture
> of Bugzilla and open projects and the status mails he is sending.  I'm not
> really sure how to formalize and write this down as a release criteria
> documents.

I guess I would say I trust Mark's mental picture better than any
formal document written down :-)

Not that I am opposed to writing things down, not at all, but
formalizing release procedures is a very hard process (we know,
we have to go through this ourselves all the time, and in fact
we generally rely on judgment from the release manager, informed
by discussion in arguable cases, rather than trying to write
down a formal set of criteria, and that has worked well for us).
> 
> Gerald

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2004-08-31 13:08 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-08-30 20:47 Ada policy (was: GCC 3.5 Status (2004-08-29)) Richard Kenner
2004-08-30 21:30 ` Laurent GUERBY
2004-08-31  9:41   ` Release criteria (was: Ada policy) Gerald Pfeifer
2004-08-31 13:29     ` Release criteria Robert Dewar

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).