Re: [Ksummit-discuss] [CORE TOPIC] Issues with stable process

[Jan Kara <jack@suse.cz>]

On Tue 14-07-15 15:31:46, Sasha Levin wrote:
> On 07/14/2015 03:18 PM, Geert Uytterhoeven wrote:
> > On Tue, Jul 14, 2015 at 9:01 PM, Sasha Levin <sasha.levin@oracle.com> wrote:
> >> > On 07/14/2015 11:56 AM, Mark Brown wrote:
> >>>>> >>>> If the issue being fixed is serious enough to take out substantial
> >>>>>>> >>>> > > portion of our test coverage or affect a lot of other development
> >>>>>>> >>>> > > usage then that's really disruptive to other work, it impacts things
> >>>>>>> >>>> > > like bisection for example.  A strong rule does nobody any good,
> >>>>>>> >>>> > > it's overkill for the problem.
> >>>>> >>> > If there's an issue that causes that effect then the original commit that
> >>>>> >>> > caused it should be reverted rather than introducing an untested fix right
> >>>>> >>> > away.
> >>>>> >>> > Obviously not a hard rule, but it should be the case in general.
> >>> >> That's still sending a change of course which was what was being
> >>> >> objected to.
> >> >
> >> > Lesser of two evils? I can't really come up with a safer solution rather than
> >> > reverting it (not blindly, the revert will need an ack too, and that's assuming
> >> > that the fix is not trivial).
> > And that it can be reverted, i.e. there are no later commits that depend on it.
> 
> Right, this it tricky - one would need to audit the commit the depend on it for
> correctness knowing that a dependency has a bug.
> 
> The premise here is that if we're not dealing with trivial breakage, reverting is
> generally safer than fixing, but for some reason we rarely take that path.

Frankly at least in my experience reverting usually happens if:

1) no other commits depend on the buggy one
2) the state after the commit is actually worse than before it (sometimes
you fix 95% of the problem and forget to fix some corner case - then
reverting would be counterproductive).

So at least in areas where I usually work things work fine in this regard.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR