This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 3.0.1
- To: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- Subject: Re: GCC 3.0.1
- From: Mark Mitchell <mark at codesourcery dot com>
- Date: Fri, 22 Jun 2001 11:04:36 -0700
- cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
> 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)?
Sorry; I should have specified. Any and all documentation patches
are OK. The reason is that the risk there is much smaller -- it
is highly unlikely we will somehow critically break the compiler by
documenting additional #pragmas, for example.
>
>> 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?
Right. Our goal is not to fix all bugs; it is to make the 3.0 series
something that everyone feels they can upgrade to safely. That means
plaform support, and that programs that used to work still do.
> 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?
I don't know. This is where GNATS really just doesn't have the
sophistication we need. Priorities should actually be release numbers;
then the priority would be the release in which we hope to fix the bug.
Is there any hope of implementing that? If not, your suggestion sounds
fine to me.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com