Re: Slush: Bug-Fixes Only for Middle End and Primary Platforms

[Steven Bosscher <stevenb dot gcc at gmail dot com>]

On Tue, Apr 28, 2009 at 11:12 PM, Mark Mitchell <mark@codesourcery.com> wrote:
> We're in Stage 1, and in Stage 1 big changes happen -- and then there is
> naturally some instability. ?We clearly have some instability at
> present, so we need to slow down until that's resolved.

Bah.


> With the benefit of hindsight, I think that committing both the SSA
> expansion and type-checking changes in close succession was probably a
> bit too much change a bit too quickly. ?When changes of this magnitude
> go in, we should probably wait a few days to see if stabilization is
> required before introducing another change of large magnitude.

Many of the changes that have gone in simply lacked testing. You
mention the type-checking changes, but that is probably the only big
change that *was* properly tested and where the failures it has caused
are just small but easily (and already) fixed.

On the other hand: It cannot be that the SSA expansion goes in without
working on half the primary targets.  That means it just wasn't tested
properly, for such a big-impact.  Was it really only tested on x86-64
before going onto the trunk?  Isn't there the "test-on-three-targets"
rule for big-impact merges?

Likewise for much of the pretty-ipa patches, which go in as "merges"
but haven't been in the branch for more than a few days in some cases.
Plus, many of the regressions were just test suite failures that, for
some reason, were overlooked or ignored before committing the patches.

Looks like the dump&go approach to me.

By contrast: I held off the gcse DF-ify patch for two weeks because I
found one (1) regression on an obscure libgomp test case during
re-testing *after* the patch had been approved. I didn't want to cause
breakage and so I first tracked down and fixed this one regression
before committing.
Now I have a backlog of ~5 tested patches to submit, but I have to
wait thanks to less careful people  :-(

Next time, a much better approach IMHO would be to just revert the
offending patches until they're properly tested and most issues are
fixed *before* the patches go on the trunk.

Ciao!
Steven