3.1 branch check-in policy questions

3.1 branch check-in policy questions

[Richard Kenner]

I have two areas where I wanted to ask if check-ins to the 3.1 branch
are appropriate.  I believe they both are, but wanted to confirm:

(1) I'd like treat Alpha/VMS support the same way as we're treating Ada: since
it's a new feature, changes just to files for it should be permitted to fix
bugs that are not necessarily regressions.

(2) I'd like to clarify that "regression" means not just something that
worked in 3.0, but things that used to work in the top-of-tree, but now
don't.  I'm thinking specifically of the Sparc bootstrap sitation (it now
fails in the Ada part of the bootstrap, but used to work) and the situation
with RTH's change of February 21, which caused some regressions, but on
things that didn't used to work (Alpha/VMS and an Ada test) with 3.0, but
worked a few weeks ago.

Do you agree?

Re: 3.1 branch check-in policy questions

[Jan Hubicka]

> I have two areas where I wanted to ask if check-ins to the 3.1 branch
> are appropriate.  I believe they both are, but wanted to confirm:
> 
> (1) I'd like treat Alpha/VMS support the same way as we're treating Ada: since
> it's a new feature, changes just to files for it should be permitted to fix
> bugs that are not necessarily regressions.
If I  understnd properly, the ADA, like Java, can be fixed because it is
not part of release criteria. Similary the Alpha/VMS is not (or x86-64/Linux
that interest me), so I interpret it as falling to same category - Alpha/VMS
specific changes are OK as long as they do not affect Alpha ports in the
release criterias.

Honza
> 
> (2) I'd like to clarify that "regression" means not just something that
> worked in 3.0, but things that used to work in the top-of-tree, but now
> don't.  I'm thinking specifically of the Sparc bootstrap sitation (it now
> fails in the Ada part of the bootstrap, but used to work) and the situation
> with RTH's change of February 21, which caused some regressions, but on
> things that didn't used to work (Alpha/VMS and an Ada test) with 3.0, but
> worked a few weeks ago.
> 
> Do you agree?

Re: 3.1 branch check-in policy questions

[Mark Mitchell]

--On Wednesday, February 27, 2002 06:56:48 AM -0500 Richard Kenner 
<kenner@vlsi1.ultra.nyu.edu> wrote:

> I have two areas where I wanted to ask if check-ins to the 3.1 branch
> are appropriate.  I believe they both are, but wanted to confirm:
>
> (1) I'd like treat Alpha/VMS support the same way as we're treating Ada:
> since it's a new feature, changes just to files for it should be
> permitted to fix bugs that are not necessarily regressions.

Yes, that's fine.  When you check those changes in, make it clear that
I approved the policy you're suggesting.

> (2) I'd like to clarify that "regression" means not just something that
> worked in 3.0, but things that used to work in the top-of-tree, but now
> don't.

I do not agree with this one.  Sometimes things get fixed in top-of-tree,
only to tickle other things, and then they get unfixed back and forth.
That's OK on the mainline, up to a point.  On the release branches we
care about regressions relative to previous releases -- any previous
release.  So, if it worked in 2.8.1, but broke in 2.95, we should
fix it before 3.1 -- but if it never worked in a released version of
GCC, it's not a regression for these purposes.  (It *is* a regression
on the mainline, and certainly should be fixed there!)

If, however, the patches get done for the mainline -- and they should,
or else we should revert the changes that caused them -- and they look
simple and safe, we can probably put them on the release branch.

It's a bit of a grey area.

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com