[N.B. -- We are not in Stage 1 yet!]
I've categorized the projects submitted for 4.3 into Stage 1 and Stage 2
projects. The criteria I've used are (a) completeness (projects that
are more complete should go in earlier), (b) riskiness (projects that
are riskier, affect more targets, etc., should go in earlier). I've
also tried to give priority to projects that were submitted for 4.2, but
didn't make it in. Feedback is welcome.
As always, you still need to get your patches reviewed before check-in;
the fact that your project is on the list doesn't imply that it will
actually be accepted, though, of course, that is the hope.
Here are some additional ground rules and notes:
* Recruit a Reviewer
If you can't approve your own contribution, please locate an appropriate
reviewer now. Find a person or people who will commit to reviewing your
patch, and put their name on your project Wiki page. Lining up a
reviewer can be more important that finishing the code; in the past,
we've had the problem of completed patches, but with no reviewer available.
* Check-in Windows
If you are contributing a project, and think you are almost ready to
check in your code, please announce that fact. From the point of your
announcement, you have a 72-hour window to get the contribution done.
During your window,, you can impose your own check-in rules on mainline.
In general, please let people to continue to check as many things in
as possible -- but if you really need to lock everything down to test on
multiple platforms, etc., you have the freedom to do that.
Before you make your reservation, you should have merged, tested, and
have had your patches reviewed. The reservation should just be for a
final merge/test/check-in cycle. When you're done, please announce that
the branch has reverted to normal rules.
* Stage 2 Projects
If you have a Stage 2 project that's ready, reviewed, and tested, you
can check in early. For example, the Stage 2 list has
architecture-specific work listed for ARM, ColdFire, and x86-64. If
that work is ready, it's unlikely to affect the Stage 1 work, so it's
fine for it to go in early. The reason it's in Stage 2 is that it
wouldn't perturb me for it to go in during Stage 2; in contrast, the new
dataflow stuff should go in soon so that we have time to fix any
problems that arise and so that future work can build on that platform.
However, if you are going to commit early, please announce that fact at
least 72 hours before you actually do your check-in, so that people
working on Stage 1 projects can ask you to wait, and please respect ay
such requests.
* Internal Ordering
I'm not going to try to order the Stage 1 projects. When you're ready,
go ahead and commit. But, please do try to keep other developers
informed of your intentions.
* Submit Early
Remember that Stage 1 isn't really the time to be doing major
development; it's primarily the time to be *merging* major development.
So, get your branches merged up to mainline, write documentation, do
tests, and submit your patches. There's no reason a patch for Stage 1
can't be completed and submitted in Stage 2/Stage 3 of the previous
release cycle. You can certainly submit your Stage 2 patch during Stage 1.
* Uncategorized Projects
I've left the Fixed-Point Arithmetic and Variadic Templates projects as
uncategorized for the moment. The fact that these projects aren't (yet)
on the merge plan doesn't mean that they're not nice projects.
However, the former looks like a very substantial change, and isn't done
yet, so my tentative feeling is that it should wait for GCC 4.4, by
which point it will hopefully be more complete. The latter requires
consensus on C++ 0x. I plan to summarize what I think the consensus is
for the development list, and then ask for SC ratification.
I'd be happy to see both of these projects in GCC 4.3 if all the pieces
come together in time.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
