Re: GCC 3.0.1

["Joseph S. Myers" <jsm28 at cam dot ac dot uk>]

On Thu, 21 Jun 2001, Mark Mitchell wrote:

> The check-in rules are similar to those preceding the 3.0 release.  
> In particular, every check-in should fix a regression from GCC 2.95.x.  
> The usual people can approve patches in the usual way.  Patches that
> cause regressions or bootstrap failures are liable to be immediately
> removed.  Proceed with caution: it is vital that we not regress
> relative to GCC 3.0 with the GCC 3.0.1 release.

What about (non-regression) documentation patches?  Should those go to the
branch (and be applied to the branch where they were applied to the
mainline only after the branch closed, e.g. merging the cpp and install
manuals from mainline)?

> In addition, we should try to fix as many other problems as possible,
> especially cases where we generate incorrect code.

That is, as many other regression problems, not other bugs?

> Let's again mark regressions from GCC 2.95.x as `high' priority bugs.  
> We don't need to analyze every bug, but if you find a new regression,
> or you look at a PR and realize it is a regression from GCC 2.95.x (or
> from GCC 3.0, heaven forbid!) mark it is as `high'. We will *not*
> necessarily fix all such bugs -- but we can try.  Marking them `high'
> will make it easy for us to find them.

What about mainline bugs that are regressions from 3.0?  Should those be 
marked "high", for convenience when working on 3.1, but have [3.1] put in 
their synopses to avoid confusing them with 3.0.1-high bugs?

-- 
Joseph S. Myers
jsm28@cam.ac.uk