[Ksummit-2012-discuss] [ATTEND] stable kernel stuff and grumpy maintainers

Mel Gorman mgorman at suse.de
Wed Jun 20 08:37:01 UTC 2012


On Tue, Jun 19, 2012 at 10:49:24AM -0700, Greg KH wrote:
> > Is it a case that the distro tree fixes are not core patches or are they
> > backports that are not getting resubmitted for -stable?
> 
> It's a case that distros are putting patches into their trees that are
> backports of bugfixes that are upstream, and are not letting me know
> that they should be included in the stable tree.
> 

err.... ok, right. I'm certainly guilty of this one. I was going to blame
bad attitude but that's not it. I considered -stable to be for functional
fixes due to reading this rule.

 - 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.

Many of the patches I backport are performance related. Some are throughput
or latency style fixes and others are interactivity related particularly
when IO is involved. These are not "critical". In some cases there are
multiple patches required and that falls foul of the "It must fix only
one thing." rule.

Hence, if I discover something really bad and fix it in mainline then I tag
it for -stable. However, I was not reposting patches for -stable that fixed
more subtle issues because they were not critical, just desirable. Maybe
the rules need a bit of a touchup or a public clarification for people
who backport for distributions but do not merge to -stable?

diff --git a/Documentation/stable_kernel_rules.txt b/Documentation/stable_kernel_rules.txt
index f0ab5cf..ddd5115d 100644
--- a/Documentation/stable_kernel_rules.txt
+++ b/Documentation/stable_kernel_rules.txt
@@ -12,6 +12,10 @@ Rules on what kind of patches are accepted, and which ones are not, into the
    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.
+ - Serious issues as reported by a user of a distribution kernel may also
+   be considered if they fix a notable performance or interactivity issue.
+   These patches should include an addendum linking to a bugzilla entry
+   if it exists and additional information on the user-visible change.
  - New device IDs and quirks are also accepted.
  - No "theoretical race condition" issues, unless an explanation of how the
    race can be exploited is also provided.



More information about the Ksummit-2012-discuss mailing list