Re: GCC 3.3, GCC 3.4

[David Edelsohn <dje at watson dot ibm dot com>]

>>>>> Tom Tromey writes:

Tom> It seems to me that when the 3.3 branch was made, people just kept
Tom> hacking on various other branches.  In fact, after 3.3 it seemed like
Tom> work on other branches accelerated in order to get them merged to the
Tom> main line as soon as possible.

Tom> I assume that happened because stage 1 and release stabilization
Tom> happen at the same time.  In other words, there is a strong incentive
Tom> to work on getting your development branch in in preference to working
Tom> on fixing regressions -- the development branches are more fun, the
Tom> window for merging them into the next release is not very long, and it
Tom> overlaps with the regression fixing period.

Tom> I suggest we change things around a bit.  For instance, maybe we could
Tom> delay branch merging until some percentage of regressions has been
Tom> fixed.  Or, extend stage 1 out past the branch's release, so that
Tom> there is no need to rush to get the new technology merged to the
Tom> trunk.

	I completely agree that the current structure of the development
plan which overlaps Stage 1 development and release branch bug fixing
discourages developers from working on bug fixes.  We are presenting
*volunteers* with a no-win situation, so we should not be surprised at the
outcome.

	Many developers missed out on getting their optimization work into
GCC 3.3 because they altruistically helped with the release engineering of
GCC 3.1.  They won't make the same mistake again.

	Taking an even stricter approach to the development process drives
developers away or encourages them to work on code forks.  The less
flexibility we demonstrate, the less we accomplish.

	Instead of the development plan being driven solely by dates, I
would like to see some technology goals.  For instance, we want to merge
in 3.4-bib, itanium-branch, pch-branch, rtlopt-branch, and new-regalloc.
We allow those branches in plan to be merged after Stage 1 and after the
GCC 3.3 release, if necessary.  That's controlled instability, as opposed
to considering any major patch far into the GCC 3.4 development cycle.  We
don't want a deluge of patches right after the GCC 3.3 release, but we
also shouldn't make it so hard for developers.  If we know ahead, we can
plan for it and developers of new optimizations on branches can plan for
it -- and hopefully contribute to bug fixing without hurting their own
optimization projects.

David