From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Joseph S. Myers" To: Mark Mitchell Cc: Subject: Re: GCC 3.0.1 Date: Fri, 22 Jun 2001 02:01:00 -0000 Message-id: References: <59980000.993156803@localhost.localdomain> X-SW-Source: 2001-06/msg01420.html 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