This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

GCC 3.0 Branch and Call For Volunteers



[ This is long, but please read it! ]

By popular request, let's slush, rather than branch, this weekend.

The goals will be:

  - Ensure that we can bootstrap on the primary GCC 3.0 release
    platforms.

  - Ensure that we can bootstrap on the secondary platforms, or
    understand why we cannot, and decide it's too hard to fix.

  - Reduce the overall bug count.

In particular, as of tomorrow (Sunday) night at midnight (GMT - 8),
let's go to the following set of rules:

  - All checkins must either:

    - Fix a bug that caues incorrect code generation, a compiler
      crash, an incorrect error message, or some other similarly
      user-visible and vital problem.

    - Provide functionality required for the release.

      For example, since we know we need to improve compile-time
      performance, a checkin that did that would be acceptable,
      even if it didn't technically fix a bug.  Similarly,
      documentation improvements, or Makefile changes required
      to build on particular platforms, or the like would be
      acceptable.

  - No checkins shall:

    - Add new optimizations

    - Improve the code generated by existing optimizations

    - Implement new language features

    - Contain ports to new architectures, not already supported
      at this time.

    - Contain changes considered likely to be substantially
      destabilizing, even if they otherwise meet these criteria.

  - The usual people can still approve patches, but they should use
    these criteria in approving patches.

The goals for these rules are to stabilize the current tree in such a
way as to give us confidence that the code from which we branch will
be sufficiently robust to allow eventual stabilization on the branch.
Once we branch, we will relax these rules, on both the branch and the
mainline.

The termination condition for this state will be one of:

  - We reach the basic goal of bootstrapping on the primary
    and secondary platforms.

  - The SC decides it's had enough.

The plan will be to branch on January 21, one week from tomorrow.
However, if we reach the bootstrapping goal earlier than that, then
we can consider branching before that point.

We will need volunteers to bootstrap/test on the various platforms.  I
will handle i686-pc-linux-gnu, and mips-sgi-irix6.5.  If you would
like to offer your assistance for one of the other listed platforms
at:

  http://gcc.gnu.org/gcc-3.0/criteria.html

please send me email privately.  Your job will be to run bootstraps
and the regression testsuite throughout the week, and let me know the
current status.  Basically, you will send me the the output of
`contrib/test_summary' after performing a bootstrap.  You can do this
by simpling saying `contrib/gcc_build checkout build test', and in
fact that is the way in which I would prefer that you accumulate this
data, since it will make things very standard across platforms.  Do
not use special --enable or --disable switches unless absolutely
necessary, and do not set BOOT_CFLAGS to non-default values.  We're
trying to see that things basically work, not bog the mainline down
indefinitely while testing everything in sight.

If you are interested in a platforms not listed at the above web page,
there is no need to conact me directly.  You can post your results to
gcc-bugs, but you should be aware that your platform's performance is
not a direct factor in the branch decision.

We will also need volunteers to help fix bugs.  If you're an able GCC
hacker, and can spare some time from other projects, please help!

Thanks to all, in advance, for your cooperation, and for your help!

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]