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