GCC 3.4 branch reopened

[Joe Buck]

On Wed, Apr 21, 2004 at 03:05:31PM +0530, Ranjit Mathew wrote:
> Mark Mitchell wrote:
> 
> > The 3.4 branch is now open for check-ins under the usual branch rules: 
> > regression fixes only, any appropriate maintainer may approve changes.
> 
> According to "Bug-fix Releases" in:
> 
>     http://gcc.gnu.org/develop.html
> 
> there is no such restriction, is there?

The release manager sets policies for release branches.  The release
manager for the 3.4 branch is Mark Mitchell.  If he says that there is a
restriction, there is a restriction.

> I mean, even if there's an "understood" restriction like
> this, I would still like to propose that it be "any bug
> fix" and not strictly "regression fixes".

The reason GCC doesn't do things that way is that, for every bug fix,
there is a significant probability that a new bug will be introduced.  A
bug fix that is not a regression means, pretty much by definition,
supporting something that was never supported before.  This usually means
new development, and that's done on development branches.  The risk of
introducing new bugs is higher in such cases.

It's considered very important that, given two releases x.y.z and
x.y.{z+1}, z+1 be consistently higher quality.  For that reason, it's not
a good idea to take risks with aggressive bug fixes in point releases.

Of course, there are exceptions: sometimes it is really true that a bug
that is not a regression has an easy and clearly safe fix.  If you
encounter such a case, ask for an exception to the rules, and it's quite
likely that an exception will be granted (depending on timing: how close
we are to the release date).

> (I understand that "regression" can be as loosely
> defined as you please, by taking a "far back enough"
> reference release of GCC, in which case this
> discussion is moot.)

Generally speaking, we go back as far as 2.95.x when labeling something as
a regression, though technically we could go further (it can be hard to
build older releases on modern OSes).