Re: Beyond GCC 3.0: Summing Up

[Richard Earnshaw <rearnsha at arm dot com>]

>     Good patchs should not prevent people from continueing their works.  I
>     think that is thee most important point: how to ensure that patch
>     checked in would not prevent people from continuing their works.
> 
> Right, but the situation we're talking about here is not a major breakage
> of that scale, but merely some regression test failures on some targets.


I think the biggest problem with your approach is priority inversion.  I 
might be in the middle of fixing a complex problem and then another change 
may break the compiler.  Before I can do any further work on my code I 
have to break off, go and fix the problem you exposed (which may then 
throw up other problems) and then remember where I got to with the 
original problem.

I'm sympathetic to both points of view, but I would add that if builds are 
breaking often I become less inclined to want to update from my working 
sources; this introduces a vicious cycle, since when I do update I'm then 
even more likely to find that things don't work...