Re: GCC 3.3, GCC 3.4

[Benjamin Kosnik <bkoz at redhat dot com>]

>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).

Ok. I didn't realize this. 

>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.

Yes! This rush to merge should be a bit more under control, or a bit
more well defined, I think. 

I'm just trying to keep 3.3 like 3.2.

>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.

I think this sounds good. Also, I like David's idea of technology
goals, or really any agreed-on list of branches to merge at all! That was
the first time I saw that. What a good idea. 

That, however, smacks of advance planning. That seems kind of scary, but
I bet the weeks immediately following a major release could be used to
could come up with some kind of hit list for the next release with
minimal effort.

>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.

I notice the exact same thing. I'm sure it could be graphed based on
mailing list activity and cvs activity.

>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.

Ditto. Review and testing seems to have overtaken my days. Three active
branches doesn't help matters, as they each have to be patched
separately and tested individually. People who do test conscientiously
are penalized by review and test cycles.

If things can be automated, they should be. I liked the autobuilder
because it was really a no-contest message: you broke it, you should fix
it (or lose the check-in). That seems pretty fair to me.

-benjamin