[lkml]   [2012]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [ 00/78] 3.3.2-stable review
    On Sun, Apr 15, 2012 at 8:49 PM, Linus Torvalds
    <> wrote:
    > On Sun, Apr 15, 2012 at 10:15 AM, Felipe Contreras
    > <> 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.



    Felipe Contreras

     \ /
      Last update: 2012-04-16 00:15    [W:0.023 / U:7.920 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site