On Fri, Jul 12, 2013 at 10:50:08AM -0700, Linus Torvalds wrote: > 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. I think that maintainers are balanced between the wish to satisfy their users and the risk of getting shouted at. Users expect stable versions to be bug-free. Most people I talk with have a different understanding of the development model than the one you present to contributors. They think that the .0 release is a draft and that all bugs will be fixed in -stable. I even know one person who uses -rc1 in production, claiming that these ones are stable. So end users don't necessarily understand the development model and ask what something they think is due : no known bugs. On the other hand, we've seen many regressions introduced as fixes into -stable that had to be reverted afterwards, or sometimes completed with a missing patch. I think that maintainers use the Cc:stable as a status for commits meaning "this is a bug fix". It's true that when you're digging into the commits to try to qualify fixes from features, it's really hard, and the new Cc:stable tag helps a lot. So probably we should incite patch contributors to add a specific tag such as "Fixes: 3.5 and later", so that non-important patches do not need the Cc:stable anymore, but users who experience an issue can easily spot them and ask for their inclusion. I've already experienced the other way around, been hit by a missing fix from 2.6.32.x that was not backported there probably because it was considered minor (and it was for most environments), except that it caused a complete web site to go down due to gro/gso issues with LVS. It's typically the type of bug that is not reported by most users, and that noone will consider critical, but once such a user encounters it, it's far too late, the harm is already done. It's too bad when both the bug and the fix are known and available, we just need to *know* they exist. While we can't ask Greg to collect all the bug fixes on the planet, we should probably do something so that end users can more easily spot what is relevant to their usage and from time to time ask for these ones to be merged if that makes sense. Willy -- 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