On 1/24/07, David Carlton <[EMAIL PROTECTED]> wrote:
On Tue, 23 Jan 2007 17:54:10 -0500, Diego Novillo <[EMAIL PROTECTED]> said:
> So, I was doing some archeology on past releases and we seem to be
> getting into longer release cycles.
Interesting.
I'm a GCC observer, not a participant, but here are some thoughts:
As far as I can tell, it looks to me like there's a vicious cycle
going on. Picking an arbitrary starting point:
1) Because lots of bugs are introduced during stage 1 (and stage 2),
stage 3 takes a long time.
2) Because stage 3 takes a long time, development branches are
long-lived. (After all, development branches are the only way to
do work during stage 3.)
3) Because development branches are long-lived, the stage 1 merges
involve a lot of code.
4) Because the stage 1 merges involve a lot of code, lots of bugs are
introduced during stage 1. (After all, code changes come with
bugs, and large code changes come with lots of bugs.)
1) Because lots of bugs are introduced during stage 1, stage 3 takes a
long time.
Now, the good news is that this cycle can be a virtuous cycle rather
than a vicious cycle: if you can lower one of these measurements
(length of stage 3, size of branches, size of patches, number of
bugs), then the other measurements will start going down. "All" you
have to do is find a way to mute one of the links somehow, focus on
the measurement at the end of that link, and then things will start
getting better.
Indeed this is a good observation. If you look at how the
linux-kernel development
changed to face and fix this problem and map this to gcc development we would
have like
1. a two-week stage1 for merging
2. six weeks for bugfixing
3. a release
1. ...
note that we would not have maintained FSF release branches, but if
time is right
vendors would pick up a release and keep it maintained (semi-officially). This
would allow focusing on "interesting" releases and avoid piling up too
much development
on branches, at the same time we can enforce more strict quality rules
on merges,
because missing one merge window is not delaying the merge for one
year (as now),
but only two month.
Note that the above model would basically force all development on
non-minor stuff
to happen on branches, "working" on the mainline is not possible in
this scheme. (This
of course fits the distributed development model of the linux kernel more)
Of course the two-week and six-week numbers are not fixed, but keeping
both numbers
low encourages good quality work (and keeping the first number low is
a requirement
anyway).
We'd have a lot of releases of course - but that's only a naming problem.
Richard.
