Re: Ada policy (was: GCC 3.5 Status (2004-08-29))

Re: Ada policy (was: GCC 3.5 Status (2004-08-29))

[Richard Kenner]

    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.

Re: Ada policy (was: GCC 3.5 Status (2004-08-29))

[Laurent GUERBY]

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

Release criteria (was: Ada policy)

[Gerald Pfeifer]

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

Re: Release criteria

[Robert Dewar]

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

Ada policy (was: GCC 3.5 Status (2004-08-29))

[Laurent GUERBY]

On Mon, 2004-08-30 at 21:28, Florian Weimer wrote:
> I understand that Ada is already in much better shape than we expected
> it to be before the tree-ssa merge (and that's certainly good news!),
> but I really doubt we should make a release criterion the quality of a
> component that has received very little testing by the general GCC
> community.

I'm just talking about bootstrap, passing ACATS and no known regression
on two targets, not "quality" in general (whatever that means).

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. 

Is that what you want for Ada now? If not, why not spell it out clearly
to avoid discussions with no time left later on? Also
if this rule is not set now, I see no reason for it to be set later
then, and that's not good news for the GNU Compiler _Collection_
Ada-wise.

Laurent

PS: I have tested and will test again at work our 500 KSLOC software
with FSF CVS.