GCC 3.0 Branch: Guidelines

[Mark Mitchell <mark at codesourcery dot com>]

As you know, we have branched for GCC 3.0.  That implies that we are,
for the most part, feature complete.

This mail contains draft guidelines for how we should handle check-ins
on the branch.  If there is widespread disagreement, we (or the SC)
can certainly choose other guidelines, but I think these will be
relatively non-controversial.

If you have questions, ask them on this list.  I'll try to reply as
best I can.

Thank you,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Goals
=====

The goal of any change checked in on the branch should be one of:

  - Fix a regression relative to GCC 2.95.[23].

    Specifically, this covers:

    - Legal code that used to compile, but now doesn't.

    - Code that used to produce a meaningful error message, but now
      causes a crash.

    - Code for which we used to generate correct code, but for
      which we now generate incorrect code.

    - Code which used to run quickly now runs markedly slower.

    - Other similar situations.

  - Improve compile-time performance.

    It is widely recognized that compile-time performance is a
    problem in the current sourc-base.  We need to work on that.
    Changes that speed up the compiler are fine, even if they do fix
    a bug.  (In some sense, you can consider these fixes for
    regressions, but let's use the term regression to apply to
    everything *but* compile-time performance.  In other words,
    regressions are things that involve the abstract performance of
    the compiler, independent of how long it takes to run, or how much
    memory it uses.)
    	
  - Fix an egregious bug, even though such a bug also appeared in GCC
    2.95.[23].

    This guideline should not be abused.  A bug is not necessarily
    egregious because it appears in a piece of software you use.  Or
    even a piece of software lots of people use.  Here are some
    examples that would qualify:

    - We miscompile the Linux kernel.

      This is an extremely piece of software from the point of view of
      the GNU Project; therefore, it must work correctly.  X Windows
      would also qualify.  The KDE CD player probably would not.
      (Note that here we are assuming the code did not work with GCC
      2.95.)

    - We emit an error message that is so misleading as to make
      fixing the first problem that appears in the source file
      next to impossible.

    - Other similar situations.

    Judgement is clearly required here.  If too many things seem
    to be being checked in under this rule, we'll have to set clearer
    guidelines, but I think that we'll develop a good feel as we
    go along.

  - Platform-specific fixes that enable platforms that do not
    presently work to work.

    Examples would include:
    
    - Fixing the HPUX back-end so that HPUX successfully bootstraps.

    - Making Makefile changes to enable the shared libgcc on platforms
      that do not presently have it.

    These changes must be sufficiently machine-specific so that is is
    clear that they will not affect other machines.

  - Some other miscellaneous, but worthwhile goal.

    I'm not really sure what these would be, but they might include
    making the compiler easier to configure, improving the packaging,
    fixing version numbers associated with various things, or what
    have you.  Let's take these case by case.

Caveats
=======

Not all patches that meet the above guidelines should be checked in.
The benefits of every patch should be weighed against the likelihood
of breakage.  Small changes are to be preferred to big ones.  Rather
than rewriting large chunks of code, we should endeavor to find
surgical changes that solve particular problems.  (That said, there
might still be moderately-sized chunks of the compiler that should be
entirely rewritten, even on the branch; that might be the best way to
solve a pervasive problem.)  In general, the goal is to avoid
regressions on the branch.

Check-in Authority
==================

All the usual maintainers can (and should!) approve patches for the
branch, following the guidelines above.