GCC 4.3 Merge Plan

[Mark Mitchell]

[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
mark@codesourcery.com
(650) 331-3385 x713