This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 3.1 branch check-in policy questions

--On Wednesday, February 27, 2002 06:56:48 AM -0500 Richard Kenner 
<> 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.


Mark Mitchell         
CodeSourcery, LLC     

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]