This is the mail archive of the
mailing list for the GCC project.
Re: 3.1 branch check-in policy questions
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Wed, 27 Feb 2002 09:14:36 -0800
- Subject: Re: 3.1 branch check-in policy questions
- References: <10202271156.AA20022@vlsi1.ultra.nyu.edu>
--On Wednesday, February 27, 2002 06:56:48 AM -0500 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.
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
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 firstname.lastname@example.org
CodeSourcery, LLC http://www.codesourcery.com