Re: [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Sun, Apr 15, 2012 at 8:49 PM, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Sun, Apr 15, 2012 at 10:15 AM, Felipe Contreras
> <felipe.contreras@xxxxxxxxx> wrote:
>>
>> This is not a reason, this is just stating what happens without
>> explaining *why*.
>>
>> Q: What changes when a tag is made?
>> A: A tag is made

[...]

> The only thing that matters is "it's been made available to others".

Exactly! Now *this* is a reason. After sending that mail I tried to
think of one since nobody else came up with it. This is in fact, a
good reason, but it implies something I'll explain below.

[...]

I do agree with all what you said above.

> And the thing is, it's not just 3.3.3 that follows 3.3.2. It's 3.4.1
> too. The reason we have the "no stable fixes before it's been
> upstreamed" (and again: a "revert" is *nothing* but another name for a
> fix, that gives some additional information about *how* we fixed
> something too) is because we want to make nice plodding reliable
> forward progress. Mistakes (== bugs) will happen, but the stable rules
> are there to make sure that those mistakes get fixed, and don't have
> long-term impact. THAT is the "stable" part of the stable series.
> Things are monotonic in the big picture, even if we may have some
> non-monotonic noise in the details.

I'm not going to argue the semantics of what is a revert, but I am
going to show the difference between the two situations:

a) v3.0* (good), v3.1* (good), v3.2* (good), v3.3 (good), v3.3.1
(bad), v3.3.2 (good), v3.4 (bad)
b) v3.0* (bad), v3.1* (bad), v3.2* (bad), v3.3 (bad), v3.3.1 (good), v3.4 (bad)

Maybe they are the same from certain point of view, but you just
argued that what *others* see is what makes the patch unrevertable,
well, it's obvious that from the point of view of the users the two
situations are clearly different. I believe it was you who said that
breaking user experience is the absolute no-no any project could
make[1]--so from that point of view a) is *much* worst.

But what is done is done, and as you said, you can't change the past,
now the important thing is what to do next. And here are the two
options' worst-case scenarios:

a.1) v3.0* (good), ... v3.3 (good), v3.3.1 (bad), v3.3.2 (bad), v3.3.3
(bad), v3.3.4 (bad), v3.3.5 (bad), v3.4 (good)
a.2) v3.0* (good), ... v3.3 (good), v3.3.1 (bad), v3.3.2 (good),
v3.3.3 (good), v3.3.4 (good), v3.3.5 (good), v3.4 (bad)

These two scenarios are unlikely, but either way, in order to
guarantee that you don't end up with a.2) You are willing to risk
going into a.1)

So, *obviously* v3.4 is more important than v3.3.x. I could argue that
the users out there would prefer a.1) any day, because it's unlikely
anyway (v3.4 would be good), but I won't.

All I want now is to agree on a reason, you have finally pointed out
that the reason for this different treatment is the user's visibility,
but that still doesn't explain why the rules for b) automatically
apply to a), since it's clearly different from the users's point of
view; if you agree that v3.4 is more important than v3.3.x, I believe
we have the reason right there.

Cheers.

[1] http://www.youtube.com/watch?v=kzKzUBLEzwk

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/