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 09:09:32AM -0400, Theodore Y. Ts'o wrote:
> On Fri, May 04, 2018 at 03:31:17PM +0300, Jani Nikula wrote:
> > On Fri, 04 May 2018, David Howells <dhowells@redhat.com> wrote:
> > > Sasha Levin via Ksummit-discuss wrote:
> > >
> > >> Cc: stable@vger.kernel.org # commit-id-of-(2)
> >
> > This has been documented since
> >
> > commit 8e9b9362266dd16255473c080d846b13e27247bf
> > Author: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
> > Date: Sun Dec 6 12:24:31 2009 +0100
> >
> > Doc/stable rules: add new cherry-pick logic
> >
> > in v2.6.33 so seems like there should have been enough time to fix the
> > tools.
>
> The problem is that it's not being *used* that way. In fact, that
> documentation is arguably out of date. When it does get used, it's
> used to indicate which kernels the stable patch applies. You have to
> go pretty far back before you find that suggested usage. Run:
>
> git log --grep stable@kernel.org | grep -i cc: | grep stable | grep \#
>
> and see for yourself. The first couple of hits:
>
> Cc: stable@kernel.org # 3.11
> Cc: stable@kernel.org # 4.8+
> Cc: stable@kernel.org # 4.8+
> Cc: stable@kernel.org # 4.13+
> Cc: stable@kernel.org # 4.8+
> Cc: stable@kernel.org # 4.13 - together with 890da9cf0983
> Cc: stable@kernel.org # 4.13
> Cc: stable@kernel.org # 4.13
> Cc: stable@kernel.org # v4.8+
> Cc: stable@kernel.org # v4.10+
> Cc: stable@kernel.org # v4.10+
> Cc: stable@kernel.org # v4.10+
> Cc: stable@kernel.org # reverted commits were marked for stable
> Cc: stable@kernel.org # for the backport of the original commit
> Cc: stable@kernel.org # v4.8+
>
> At this point, my suggestion would be to delete the text added by the
> above-mentioned commit, and add a new syntax. We're much more willing
> to support multiple headers, so something like this:
>
> Stable-prereq: DEADBEEF1234: subsystem: bork bork bork....
>
> With multiple Stable-preeq: lines allowed, where the order is
> significant, might be one way to do things.

Ugh, what? I don't understand what you are proposing here, what we have
today is just fine, what is broken with it?

thanks,

greg k-h

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