stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: ksummit-2013-discuss@lists.linuxfoundation.org
Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: KS Topic request: Handling the Stable kernel, let's dump the cc: stable tag
Date: Mon, 15 Jul 2013 23:27:56 +0400	[thread overview]
Message-ID: <1373916476.2748.69.camel@dabdike> (raw)

Before the "3.10.1-stable review" thread degenerated into a disagreement
about habits of politeness, there were some solid points being made
which, I think, bear consideration and which may now be lost.

The problem, as Jiří Kosina put is succinctly is that the distributions
are finding stable less useful because it contains to much stuff they'd
classify as not stable material.

The question that arises from this is who is stable aiming at ...
because if it's the distributions (and that's what people seem to be
using it for) then we need to take this feedback seriously.

The next question is how should we, the maintainers, be policing commits
to stable.  As I think has been demonstrated in the discussion the
"stable rules" are more sort of guidelines (apologies for the pirates
reference).  In many ways, this is as it should be, because people
should have enough taste to know what constitutes a stable fix.  The
real root cause of the problem is that the cc: stable tag can't be
stripped once it's in the tree, so maintainers only get to police things
they put in the tree.  Stuff they pull from others is already tagged and
that tag can't be changed.  This effectively pushes the problem out to
the lowest (and possibly more inexperienced) leaves of the Maintainer
tree.  In theory we have a review stage for stable, but the review
patches don't automatically get routed to the right mailing list and the
first round usually comes out in the merge window when Maintainers'
attention is elsewhere.

The solution, to me, looks simple:  Let's co-opt a process we already
know how to do: mailing list review and tree handling.  So the proposal
is simple:

     1. Drop the cc: stable@ tag: it makes it way too easy to add an ill
        reviewed patch to stable
     2. All patches to stable should follow current review rules: They
        should go to the mailing list the original patch was sent to
        once the original is upstream as a request for stable.
     3. Following debate on the list, the original maintainer would be
        responsible for collecting the patches (including the upstream
        commit) adjudicating on them and passing them on to stable after
        list review (either by git tree pull or email to stable@).

I contend this raises the bar for adding patches to stable much higher,
which seems to be needed, and adds a review stage which involves all the
original reviewers.

Oh, and did someone mention plum brandy ...?

James



             reply	other threads:[~2013-07-15 19:27 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-15 19:27 James Bottomley [this message]
2013-07-15 19:45 ` [Ksummit-2013-discuss] KS Topic request: Handling the Stable kernel, let's dump the cc: stable tag Steven Rostedt
2013-07-15 19:55   ` Willy Tarreau
2013-07-15 20:56     ` Steven Rostedt
2013-07-15 21:09       ` Joe Perches
2013-07-15 21:21         ` Steven Rostedt
2013-07-15 21:34           ` Joe Perches
2013-07-21  4:06         ` Rob Landley
2013-07-15 21:52       ` Willy Tarreau
2013-07-15 20:15   ` Mark Brown
2013-07-15 21:07     ` Steven Rostedt
2013-07-15 20:19 ` Guenter Roeck
2013-07-15 22:04   ` David Woodhouse
2013-07-15 22:07     ` Guenter Roeck
2013-07-15 22:38       ` H. Peter Anvin
2013-07-15 23:22         ` Guenter Roeck
2013-07-16  0:13           ` H. Peter Anvin
2013-07-16  0:21             ` Greg KH
2013-07-16  0:25               ` H. Peter Anvin
2013-07-16 15:50                 ` Paul Gortmaker
2013-07-15 20:20 ` Jason Cooper
2013-07-15 21:44 ` Greg KH
2013-07-15 21:55   ` Greg KH
2013-07-15 22:01     ` H. Peter Anvin
2013-07-15 23:08       ` Greg KH
2013-07-16  0:40         ` [Ksummit-2013-discuss] " Rafael J. Wysocki
2013-07-16  9:06       ` Jiri Kosina
2013-07-15 22:01   ` Steven Rostedt
2013-07-16  0:06     ` Greg KH
2013-07-16  2:09       ` Steven Rostedt
2013-07-16  2:41         ` Ben Hutchings
2013-07-16  3:27           ` Dave Airlie
2013-07-16  3:43             ` Steven Rostedt
2013-07-16  4:10             ` Ben Hutchings
2013-07-16  6:23             ` Greg KH
2013-07-16  6:10       ` James Bottomley
2013-07-16  6:28         ` Greg KH
2013-07-15 22:22   ` Jiri Kosina
2013-07-15 23:40     ` Jiri Kosina
2013-07-15 23:59     ` Greg KH
2013-07-16  2:30   ` Ben Hutchings
2013-07-16  6:13     ` Greg KH
2013-07-16  9:11       ` Jiri Kosina
2013-07-16 16:36         ` Greg KH
2013-07-17  3:53           ` Ben Hutchings
2013-07-17  4:24             ` Greg KH
2013-07-16  5:17   ` James Bottomley
2013-07-16  6:20     ` Greg KH
2013-07-16  7:43       ` [Ksummit-2013-discuss] " James Bottomley
2013-07-16  9:46         ` Jiri Kosina
2013-07-16 12:43           ` Ben Hutchings
2013-07-16 16:35           ` Greg KH
2013-07-16 23:15             ` Jiri Kosina
2013-07-16 13:14         ` Josh Boyer
2013-07-17 15:08         ` John W. Linville
2013-07-18  7:45           ` Kalle Valo
2013-07-16 10:02       ` Jan Kara
2013-07-16  6:24   ` David Lang
2013-07-16 16:45     ` [Ksummit-2013-discuss] " Steven Rostedt
2013-07-16  2:00 ` Ben Hutchings
2013-07-16  9:53   ` Mark Brown
2013-07-21  4:11 ` Rob Landley
2013-07-21 15:09   ` [Ksummit-2013-discuss] " Ben Hutchings
2013-07-22 21:24     ` KOSAKI Motohiro
2013-07-23  2:29       ` Li Zefan
2013-07-23  2:40 ` Myklebust, Trond
2013-07-23  2:47   ` James Bottomley
2013-07-23  2:57     ` Myklebust, Trond

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1373916476.2748.69.camel@dabdike \
    --to=james.bottomley@hansenpartnership.com \
    --cc=ksummit-2013-discuss@lists.linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).