Re: [RFC] A policy for supported ports and targets

["Joseph S. Myers" <jsm at polyomino dot org dot uk>]

On Mon, 21 Jun 2004, Richard Sandiford wrote:

> No we're not!  At least not on those terms.  No-one every promised that
> 3.4 would be a high-quality ip2k release.  And of course there's the
> usual disclaimer:

We operate a "no regressions" policy, and set all regression PRs to have
the next release as target milestone, even though the formal patch
reversion policy only specifies reversion for patches causing regressions
on important targets, and the 3.4 release criteria only promise no
testsuite regressions on a certain list of platforms.

Any non-deliberate difference in GCC, its behavior or its documentation,
on any platform, that arguably makes a later version worse than an earlier
version (whether an ancestral version, or a chronologically prior version
from an earlier release branch, and whether the earlier version is a CVS
mainline version or any prerelease or release or release branch version of
GCC1, GCC2, EGCS or GCC3) is in my view a regression.  We then disregard
certain categories (for example, only considering regressions from prior
releases, not CVS versions, as relevant for release policy), and postpone 
other regressions to later releases (with the particular release from 
which something is a regression being a relevant consideration; a 
regression from 2.7 is still a regression, but people have evidently been 
living with it broken for a long time).

I'd like to see automated regression testers for all primary and secondary
release platforms (reporting bugs for regressions found, and if necessary
moving the tree to Stage 3 mode - bugfixes only - when regressions on any
such platform remain unfixed for too long, as sometimes they do), but that
would require rather large resources to set up.  Automated testers for all
other CPU targets (again, reporting the regressions so the people who
might have caused them know about them) would be nice as well - quite
likely those bugs will be postponed to subsequent releases if no-one acts
to fix them, but this should be an explicit act rather than accidentally 
releasing a compiler that is completely broken on the target.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)