lkml.org 
[lkml]   [2013]   [Jul]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [ 00/19] 3.10.1-stable review
    From
    On Fri, Jul 12, 2013 at 10:31 AM, Guenter Roeck <linux@roeck-us.net> wrote:
    >
    > Stable rules say: "It must fix a real bug that bothers people (not a, "This
    > could be a problem..." type thing). All the above fit that rule.

    You cut out the important part:

    - It must fix a problem that causes a build error (but not for things
    marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
    security issue, or some "oh, that's not good" issue. In short, something
    critical.

    That list is not a "or" list, it's an "and" list - it needs to follow
    *all* the rules. The exception is the "New device IDs and quirks are
    also accepted", which maybe should be made more clearly separate.

    > But are those patches critical ? Sure, people complained about getting alarms
    > on the wrong attribute or not getting alarms when they expected to, but critical ?
    > No, unless some application at some point starts to shut down the system because
    > of a false alarm. So I guess the above should not go into -stable, then.

    Right. And that's what the stable rules say. It's not enough to be a
    "real bug". It needs to be critical. If it's something that has been
    around forever, there needs to be a stronger argument than "I found a
    bug" for marking it for stable.

    > Problem is with "bothers people" vs. "critical".

    There is no "vs".

    The "real bug that bothers people" rule is not meant to be seen as a
    separate rule from the next rule (already quoted above), it needs to
    be *in*addition*to*.

    For example, we have the "causes a build error" case - but that should
    be seen in the "real bug that bothers people" light, and you should
    not mark Kconfig fixes for stable unless they have actually caused
    problems. Why? Because most Kconfig problems tend to be for
    unrealistic situations like "Oh, if I turn off PCI or networking, this
    driver no longer builds". Sure, that is a bug, and it's a bug that
    causes build error, but it's not something that bothers real people,
    because if you turn off networking or turn off PCI, you damn well had
    better also turn off all the other crap you don't need.

    Yes, there are always going to be gray areas. And Greg is obviously a
    much nicer person than I am, so he's likely *always* going to be more
    generous about those gray aras than I would be. And within reason, I
    think that's perfectly fine - if there's a few patches that get marked
    for stable because it's easier for people to sneak them in that way,
    whatever. It becomes a problem only when it gets to be *too* common,
    which is apparently what happened now.

    So I'm not going to argue that your particular patches were the
    problem here. I'm more arguing against your arguments than against the
    patches themselves. I'm not looking for some hard black-and-white
    rules that say "this is exactly how things have to work", because I
    don't think such rules can exist. But I _do_ want people to see the
    stable rules as fairly strict. And in particular, I really don't think
    people should see "post-rc4" to be any different from "stable".

    If anything, I think post-rc4 should be easier to get into, if only
    because post-rc4 has the additional "hey, if it's new code that hasn't
    seen a release yet, we can be much more aggressive about it". For
    example, I think I'm *much* more open to reverting new commits
    entirely in the late rc's than we should ever be for stable.

    Linus


    \
     
     \ /
      Last update: 2013-07-12 20:41    [W:4.036 / U:0.176 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site