Re: GCC 3.3, GCC 3.4

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Joe" == Joe Buck <jbuck@synopsys.com> writes:

Joe> If 3.3 can be stabilized to the point where almost all the high-priority
Joe> bugs are fixed in it, then 3.3 (with its other improvements) would
Joe> be preferable to 3.2.3 (which may have bug fixes, but doesn't have 3.3's
Joe> new features).  This is especially the case for any bugs that depend
Joe> on new infrastructure to fix.

Whether 3.3 is preferable depends on what you're using it for.  For
gcj users, 3.3 is hugely better.  I'd really, really like a 3.3, just
to get all the bug fixes out to the public.  For gcj there's really no
comparison (gcj and libgcj are still changing quickly; each major
release is visible different from the previous one).

Joe> As the third digit increases, we should be more and more cautious
Joe> about what kinds of changes we apply.  If we wind up backporting
Joe> large patches, it might be safer to just postpone fixes until
Joe> 3.3.

Yeah.  Back-porting the gcj fixes would be a huge effort.

Joe> Still, I'm worried about whether we really have the resources to
Joe> have three flows going at once on a continuing basis.  As long as
Joe> we do, I think that the middle one (3.3) will suffer: lots of
Joe> testing and fixing on 3.2, lots of gurus working on the cool
Joe> stuff in 3.4, but little effort on 3.3.

I worry about that too, especially since for gcj we decided not to do
any further work on 3.2 (a mistake we won't repeat in the future --
clearly pushing bug fixes to the older release is worthwhile).  It
seems to me that when the 3.3 branch was made, people just kept
hacking on various other branches.  In fact, after 3.3 it seemed like
work on other branches accelerated in order to get them merged to the
main line as soon as possible.

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

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

For gcj at least, when a release branch is made (this happened for 3.1
and now 3.3), it seems like tons of patches come out of the woodwork.
Suddenly patch review is a major part of my day.  I don't know what to
do about this.  I hate to prevent a bug fix from going into the next
release just because the timing is inconvenient.  On the other hand,
it makes doing a release that much harder.

Tom