On Mon, 16 Apr 2018 18:35:44 +0000 Sasha Levin <Alexander.Levin@xxxxxxxxxxxxx> wrote: > If I were to tell you that I have a crack team of 10 kernel hackers who > dig through all mainline commits to find commits that should be > backported to stable, and they do it with less mistakes than > authors/maintainers make when they tag their own commits, would I get the > same level of objection? Probably ;-) I've been struggling with my own stable tags, and been thinking that I too suffer from tagging too much for stable, because there's code I fix, and think "hmm, this could have some unwanted side effects". I'm actually worried that my own fixes could cause an API breakage that I'm unaware of. What I'm staying is, I think we should start looking at fixes that fix bugs we consider critical. Those being: * off-by-one * memory overflow * locking mismatch * API regressions For my sub-system * wrong data coming out Which can be a critical issue. Wrong data is worse than no data. But then, there's the times a bug will produce no data, and considering what it is, and how much of an effort it takes to fix it, I may or may not label "no data" issues for stable. The cases where I enable something with a bunch of parameters, and because of some mishandling of the parameter it just screws up totally (where it's obvious that it screwed up), I only mark those for stable if it doesn't require a redesign of the code to fix it. There's been some cases where a redesign was required, and I didn't mark it for stable. The fixes for tracing that I don't usually tag for stable is when doing complex tracing simply doesn't work and produces no data or errors incorrectly. Depending on how complex the fix is, I mark it for stable, otherwise, I think the fix is more likely to break something else that is more common, then this hardly ever used feature. The fact that nobody noticed, or hasn't complained about it usually plays a lot in that decision. If someone complained to me about breakage, I'm more likely to label it for stable. But if I discover it myself, as I probably use the tracing system differently than others as I wrote the code, then I don't usually mark it. -- Steve