Important: Development Plan for Future Releases

[Mark Mitchell <mark at codesourcery dot com>]

The Steering Committee has, after much deliberation, and after
considering the various opinions presented on the public mailing
lists, adopted the proposal detailed below.  This policy will
govern the development of GCC henceforth; it is important that
all developers understand the policy.

As Bernd pointed out, any policy that could be mechanically enforced
is too simplistic.  Therefore, there are aspects of this policy that
are under-specified.  We will address gray areas on a case-by-case
basis.  There are no absolutes; exceptions can be made by the SC to
any of these provisions.  And, of course, we understand that this
policy is very likely to require revisions as we go forward.

Although many parts of this policy follow the outline I presented some
weeks back, changes have been made in many places, and, some very
important goals, such as support for more targets, have been made a
bigger focus.  I would like to thank everyone for their contributions
to the debate, and especially (in alphabetical order) Per Bothner, Joe
Buck, Robert Dewar, David Edelsohn, Richard Kenner, H.J. Lu, Joseph
Meyers, Alexandre Oliva, Gerald Pfeifer, Bernd Schmidt, and Joel
Sherill for taking the time to make very substantial contributions.

Thank you in advance for your willingness to go along with this
experiment.  I hope and believe that it will work out well.  If it
does not, we will try something different!

So as to avoid surprising anyone, the first Stage 1 (see below) period
will begin August 15th, 2001.  Therefore, GCC 3.1 will be released on
or about April 15, 2002.  In the meantime, we will continue to make
bug-fix releases based on GCC 3.0.x.

--

I. Objectives

  The goals of this policy are:

    - Higher-quality releases

    - Support for more targets

    - Continued encouragement of major infrastructure improvements

    - More predictable release schedules

    - More frequent releases

  Rationale:

    It has been difficult for us to make consistent, high-quality
    releases that support a wide variety of targets.  In particular,
    GCC 3.0 achieved a high standard of quality on many targets,
    but was by no means perfect, and failed to support as many
    targets as we would have liked.

    In addition, the release was late relative to original scheduling
    estimates.  And, the time between the GCC 2.95 and GCC 3.0
    releases was longer than everyone would have liked.  We think that
    we will better serve the user community by making releases
    somewhat more frequently, and on a consistent schedule.

    In addition, a consistent schedule will make it possible for
    the Release Manager to better understand his or her time
    commitment will be when he or she agrees to take the job.

II. Development Methodology

  Branches:

    The development of major changes shall be done on a branch.  (Under
    some circumstances, development may be done in a private development
    tree, but the Steering Committee strongly encourages the use of
    a branch in the publicly accessible GCC development tree.)

    Examples of major changes include:

    - A new C++ parser

    - A new memory allocation scheme for internal use in the compiler

    - A new optimization pass

    There is no firm guideline for what constitutes a "major change"
    and what does not.  If a developer is unsure, she should ask for
    guidance on the GCC mailing lists.  In general, a change that
    has the potential to be extremely destabilizing should be done
    on a branch.

    Changes may be merged from a branch only after:

    - They meet the standards for any other check-in.  For example,
      the code must be well-documented, and any user-visible
      changes, including command-line options, should be documented
      in the manual.

    - The branch has been validated on three different targets,
      each targeting a different microprocessor family.  Validation
      should consist of bootstrapping the compiler (unless that is
      impossible for the microprocessor selected) and checking that
      there are no new regression test failures.  It is acceptable
      to use a simulator for validation; the use of real hardware
      is not required.

  Rationale:

    Making major improvements to the compiler is good.  However, such
    changes are inevitably somewhat destabilizing.  By using a branch,
    it is possible for people to test and improve the code, but
    without impacting other developers.  By testing major changes more
    thoroughly than ordinary changes, we will help reduce the impact
    on other developers.

    In addition, the presence of half-finished projects on the
    mainline presents a variety of problems when preparing for a
    release.  If serious bugs remain, it may be impossible to do
    a release until the bugs are fixed, thereby impacting the
    release schedule.  If functionality is present, but not robust
    (for example, command-line options that activate an optimization
    pass that does not work very well), then we can seriously
    confuse users.

  Schedule:

    Development on our main branch will proceed in three stages.  Each
    stage will be two months in length.

    Stage 1
    -------

    During this period, changes of any nature may be made to the
    compiler.  In particular, major changes may be merged from
    branches.

    Stage 2
    -------

    During this period, major changes may not be merged from branches.
    However, other smaller improvements may be made.  For example,
    support for a new language construct might be added in a
    front-end, or support for a new variant of an existing
    microprocessor might be added to a back-end.

    Stage 3
    -------

    During this period, the only changes that may be made to the
    compiler are changes that fix bugs.  New functionality may
    not be introduced during this period.

  Rationale:

    In order to produce releases on a regular schedule, we must
    ensure that the mainline is reasonably stable some time before
    we make the release.  Therefore, more radical changes must be
    made earlier in the cycle, so that we have time to fix any
    problems that result.

    In order to reach higher standards of quality, we must focus on
    fixing bugs; by working exclusively on bug-fixing through Stage 3,
    we will have a higher quality source base as we prepare for a
    release.

    Although maintaining a branch, including merging new changes
    from the mainline, is somewhat burdensome, the absolute worst
    case is that such a branch will have to be maintained for four
    months.  During two of those months, the only mainline changes
    will be bug-fixes, so it is unlikely that many conflicts will
    occur.

  Patch Reversion:

    If a patch is committed which introduces a regression [1], on any
    target which the Steering Committee considers to be important [2],
    and the problem is reported to the original poster, and 48 hours
    pass without either the original poster or any other party
    indicating that a fix will be forthcoming in the very near future,
    and two people with write privileges to the affected area of the
    compiler determine that the best course of action is to revert the
    patch, then they may revert the patch.

    After the patch has been reverted, the poster may appeal the
    decision to the Steering Committee.

  Rationale:

    If an important platform is broken, then it will be difficult
    to prepare a release.  If nobody volunteers to fix the problem,
    then we will have an unpleasant choice: delay the release, or
    release a compiler that we know to be worse than the previous
    release.  Therefore, it is important that we be able to revert
    patches that cause problems.  In addition, regressions on the
    mainline can impede the development of other improvements.

    On the other hand, we want to encourage new development, and
    new development inevitable introduces new bugs.  Therefore,
    it is important that decisions be made on a case-by-case basis,
    and that the proponent of a change have an opportunity to argue
    that the benefits of the change outweigh the costs.  Therefore,
    the decision to revert requires two consenting parties, and
    such decisions may be appealed to the Steering Committee.
    However, during the appeal, the mainline will remain working, to
    avoid impeding other development.

III. Release Methodology

  Schedule:

    At the conclusion of Stage 3 above, a release branch will be
    created.

    On the release branch, the focus will be fixing any regressions
    from the previous release, so that each release is better than
    the one before.

    The release will occur two months after the creation
    of the branch.  (Stage 1 of the next release cycle will occur
    in parallel.)  If, however, support for an important platform has
    regressed significantly from the previous release or support for a
    platform with active maintenance has regressed significantly relative
    to an earlier Stage in the current release cycle, the release will be
    postponed until the regressions are corrected, unless the Steering
    Committee releases the automatic hold on the release.

  Rationale:

    While making releases on schedule is important, quality should
    not be subordinate to schedule.  If a major platform is not
    adequately supported, but was well supported previously,
    then we should address the problems.  Presumably, this
    will not be unduly difficult, since we will have spent four
    months fixing bugs by the time the release would occur.

   Bug-fix Releases:

     Bug-fix releases will be made two and four months after the
     initial release, as necessary.

   Rationale:

     By waiting for two months to make a bug-fix release, we will
     be able to accumulate fixes for the most important problems,
     and avoid spending undue amounts of time on release testing
     and packaging.

Footnotes
---------

[1] Note that no distinction is made between patches which are
    themselves buggy and patches which expose "latent" bugs
    elsewhere in the compiler.

[2] The Steering Committee is planning to prepare a list of such
    targets.   The list will be revised at the beginning of each
    release cycle, if necessary.