GCC 3.3, GCC 3.4

[Tom Tromey]

>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:

Mark> That's basically a feature-driven approach -- "we want these new
Mark> features".  The problem with that is that we have no way of
Mark> knowing whether people will actually do the work to implement
Mark> the features or not.

Perhaps I misunderstood David's suggestion.

What I understood is that we would have a mix between a feature-driven
approach and a date-driven approach.

For small patches and features, we would use dates and stages as we do
now.

For the merging of major branches, we would make determinations based
on features, presumably modified by the likelihood of a given branch
being ready.

I see this idea more as a realignment of our current approach than a
major new approach.  In particular I think it tries to address a
specific problem, namely that some of our core developers have
incentive to avoid working on a release branch in favor of getting
their new work into the main line.

Mark> Right now, we have a window in which to merge branches.  If
Mark> you're ready, you merge; if you're not, you don't.  We
Mark> successfuly merged some major technology that way for 3.4.

I agree, and I wouldn't change the readiness requirement.

It seems to me that the merges for 3.4 were timed in such as way as to
cause a penalty for 3.3.  For instance, my impression is that the new
C++ parser required many bug fixes after it was merged in.  Since the
Stage 1 window is pretty narrow, you had a lot of incentive to merge
it as soon as the window opened.  This meant a lot of unavoidable bug
fixing (I think we can assume that no branch will get as much testing
as the trunk, and therefore any major merge will be bug-free mostly by
accident) during the time that 3.3 was, in theory, also being
prepared.

I don't think any of these decisions were made in error, especially
given current rules.

However, perhaps the timing could have been different with a different
approach to the stages.  For instance, when the 3.3 branch was made we
could have all agreed: "PCH, the new C++ parser, and the new RA will
all be in 3.4 -- they are all major new features that we collectively
consider to be ready.  However, the priority is to stabilize 3.3.  So,
if a merge of one of these branches goes past the ordinary stage 1
dates, that's ok".  We can still apply the usual thinking we apply
right now.  For instance, tree-ssa wasn't ready for 3.3 by the old
rules, and it wouldn't be by the new ones either.  If it somehow was
prepared before, say, PCH was merged in, we could still say "no, that
is a 3.4 feature".

Tom