On Fri, Jul 12, 2013 at 10:31 AM, Guenter Roeck <linux@xxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html