[cygnus.egcs] GCC 3.0 Branch and Call For Volunteers

[Tom Tromey]

I read this today on the gcc list.

Here's what I think we should do for Java:

* Commit the new ABI patch as soon as it can build the runtime and
  make a working `hello world'.  I think it is very important that
  this go in before the branch is made.  Lingering bugs like the
  `int.class' problem can be handled as critical bugs during the
  actual release process.

* Write documentation for gcj.  I've just barely started this.

* Move the Java web pages, mailng lists, etc, to gcc.gnu.org.
  This can be done in pieces.

* Delay the RMI and Win32 libffi changes until the 3.0 branch is
  made.  Then check them in on the trunk for 3.1 (assuming 3.1 will be
  given a new branch).

* Only check in high-priority or low-risk bug fixes.

Comments?  Disagreements?  Suggestions?

Tom
------- Start of forwarded message -------
From: Mark Mitchell <mark@codesourcery.com>
Subject: GCC 3.0 Branch and Call For Volunteers
Date: Sat, 13 Jan 2001 14:58:58 -0800
Organization: CodeSourcery, LLC
Message-ID: <20010113145858R.mitchell@codesourcery.com>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: gcc@gcc.gnu.org, gcc-patches@gcc.gnu.org


[ 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
------- End of forwarded message -------