lkml.org 
[lkml]   [2018]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Ksummit-discuss] bug-introducing patches
On Fri, May 04, 2018 at 10:40:55AM -0700, Greg KH wrote:
> Ugh, what? I don't understand what you are proposing here, what we have
> today is just fine, what is broken with it?

What we have today is this:

Cc: stable@kernel.org # 3.11
Cc: stable@kernel.org # 4.8+
Cc: stable@kernel.org # 4.8+

Jani was suggesting something documented which doesn't match current
practice. See commit 8e9b9362266d, which describes something like this:

Cc: <stable@kernel.org> # .32.x: a1f84a3: sched: Check for idle
Cc: <stable@kernel.org> # .32.x: 1b9508f: sched: Rate-limit newidle
Cc: <stable@kernel.org> # .32.x: fd21073: sched: Fix affinity logic

... to specify prereqisite commits needed to backport the commit in
question. I am proposing that we delete what is in
stable_kernel_rules.rst, because it doesn't match with current
practice.

If it is necessary to explicitly specify prerequisites (as opposed to
having scripts or stable maintainers guess or figure things out
manually), then something like this might be better:

Stable-prereq: DEADBEEF1234: subsystem: bork bork bork....

If it's not necessary, fine. But we should still delete what is
currently documented in stable_kernel_rules and was introduced in
8e9b9362266d, because it doesn't describe current practice.

- Ted

\
 
 \ /
  Last update: 2018-05-04 23:13    [W:0.104 / U:1.480 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site