On Fri, Jul 12, 2013 at 09:50:51PM +0200, Willy Tarreau wrote: > 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. Huh? What's wrong with the existing way people mark stable patches to go back to much older kernel versions? Is that not working well enough for you? And if something "fixes" an issue, then I want it in stable, just like Linus wants that in his tree. Don't add another tag that requires users to dig for fixes that we are just too lazy to be including for all users, that way is crazy. greg k-h -- 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