This is the mail archive of the
mailing list for the Java project.
[cygnus.egcs] GCC 3.0 Branch and Call For Volunteers
- To: Java Discuss List <java-discuss at sourceware dot cygnus dot com>
- Subject: [cygnus.egcs] GCC 3.0 Branch and Call For Volunteers
- From: Tom Tromey <tromey at redhat dot com>
- Date: 14 Jan 2001 15:49:31 -0700
- Reply-To: tromey at redhat dot com
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?
------- Start of forwarded message -------
From: Mark Mitchell <email@example.com>
Subject: GCC 3.0 Branch and Call For Volunteers
Date: Sat, 13 Jan 2001 14:58:58 -0800
Organization: CodeSourcery, LLC
Content-Type: Text/Plain; charset=us-ascii
To: firstname.lastname@example.org, email@example.com
[ 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
- 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
- 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
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
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 firstname.lastname@example.org
CodeSourcery, LLC http://www.codesourcery.com
------- End of forwarded message -------