linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: ksummit-2013-discuss@lists.linuxfoundation.org,
	"John W. Linville" <linville@tuxdriver.com>,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org,
	ksummit-2013-discuss@lists.linux-foundation.org,
	torvalds@linux-foundation.org
Subject: Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
Date: Fri, 12 Jul 2013 18:32:11 -0700	[thread overview]
Message-ID: <20130713013211.GA22726@kroah.com> (raw)
In-Reply-To: <2354417.lhslZaMQMB@vostro.rjw.lan>

On Sat, Jul 13, 2013 at 02:24:07AM +0200, Rafael J. Wysocki wrote:
> On Thursday, July 11, 2013 08:34:30 PM Greg Kroah-Hartman wrote:
> > On Thu, Jul 11, 2013 at 10:57:46PM -0400, John W. Linville wrote:
> > > On Thu, Jul 11, 2013 at 08:50:23PM -0400, Theodore Ts'o wrote:
> > > 
> > > > In any case, I've been very conservative in _not_ pushing bug fixes to
> > > > Linus after -rc3 (unless they are fixing a regression or the bug fix
> > > > is super-serious); I'd much rather have them cook in the ext4 tree
> > > > where they can get a lot more testing (a full regression test run for
> > > > ext4 takes over 24 hours), and for people trying out linux-next.
> > > > 
> > > > Maybe the pendulum has swung too far in the direction of holding back
> > > > changes and trying to avoid the risk of introducing regressions;
> > > > perhaps this would be a good topic to discuss at the Kernel Summit.
> > > 
> > > Yes, there does seem to be a certain ebb and flow as to how strict
> > > the rules are about what should go into stable, what fixes are "good
> > > enough" for a given -rc, how tight those rule are in -rc2 vs in -rc6,
> > > etc.  If nothing else, a good repetitive flogging and a restatement of
> > > the One True Way to handle these things might be worthwhile once again...
> > 
> > The rules are documented in stable_kernel_rules.txt for what I will
> > accept.
> > 
> > I have been beating on maintainers for 8 years now to actually mark
> > patches for stable, and only this past year have I finally seen people
> > do it (we FINALLY got SCSI patches marked for stable in this merge
> > window!!!)  So now that maintainers are finally realizing that they need
> > to mark patches, I'll be pushing back harder on the patches that they do
> > submit, because the distros are rightfully pushing back on me for
> > accepting things that are outside of the stable_kernel_rules.txt
> > guidelines.
> 
> I don't quite understand why they are pushing back on you rather than on
> the maintainers who have marked the commits they have problems with for
> -stable.  Why are you supposed to play the role of the gatekeeper here?
> Can't maintainers be held responsible for the commits they mark for -stable in
> the same way as they are responsible for the commits they push to Linus?

Because I'm an easy big target and people are lazy.

> Also, I don't really think that the distros have problems with fixes that are
> simple and provably correct, even though the problems they fix don't seem to be
> "serious enough" for -stable.  They rather have problems with subtle changes
> whose impact is difficult to estimate by inspection and you're not going to be
> pushing back on those anyway (exactly because their impact is difficult to
> estimate).

I know that, you know that, but managers who see tons of kernel patches
just get scared :)

> > If you look on the stable@vger list, I've already rejected 3 today and
> > asked about the huge 21 powerpc patches.  Sure, it's not a lot, when
> > staring down 174 more to go, but it's a start...
> 
> And 2 of those 3 rejected were mine and for 1 of them I actually had a very
> specific reason to mark it for -stable as I told you: It fixed a breakage
> introduced inadvertently in 3.10 and I thought it would be good to reduce
> the exposure of that breakage by fixing it in 3.10.1 as well as in 3.11-rc.

There was no real breakage, that is why I rejected it.

greg k-h

  reply	other threads:[~2013-07-13  1:31 UTC|newest]

Thread overview: 125+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-11 22:01 [ 00/19] 3.10.1-stable review Greg Kroah-Hartman
2013-07-11 22:01 ` [ 01/19] libceph: Fix NULL pointer dereference in auth client code Greg Kroah-Hartman
2013-07-11 22:01 ` [ 02/19] ceph: fix sleeping function called from invalid context Greg Kroah-Hartman
2013-07-11 22:01 ` [ 03/19] libceph: fix invalid unsigned->signed conversion for timespec encoding Greg Kroah-Hartman
2013-07-11 22:01 ` [ 04/19] drivers/cdrom/cdrom.c: use kzalloc() for failing hardware Greg Kroah-Hartman
2013-07-11 22:01 ` [ 05/19] module: do percpu allocation after uniqueness check. No, really! Greg Kroah-Hartman
2013-07-11 22:01 ` [ 06/19] charger-manager: Ensure event is not used as format string Greg Kroah-Hartman
2013-07-11 22:01 ` [ 07/19] hpfs: better test for errors Greg Kroah-Hartman
2013-07-11 22:01 ` [ 08/19] block: do not pass disk names as format strings Greg Kroah-Hartman
2013-07-11 22:01 ` [ 09/19] crypto: sanitize argument for format string Greg Kroah-Hartman
2013-07-11 22:01 ` [ 10/19] MAINTAINERS: add stable_kernel_rules.txt to stable maintainer information Greg Kroah-Hartman
2013-07-11 22:01 ` [ 11/19] futex: Take hugepages into account when generating futex_key Greg Kroah-Hartman
2013-07-11 22:01 ` [ 12/19] tty: Reset itty for other pty Greg Kroah-Hartman
2013-07-11 22:01 ` [ 13/19] Revert "serial: 8250_pci: add support for another kind of NetMos Technology PCI 9835 Multi-I/O Controller" Greg Kroah-Hartman
2013-07-11 22:01 ` [ 14/19] NFSv4.1 end back channel session draining Greg Kroah-Hartman
2013-07-11 22:01 ` [ 15/19] nfsd4: fix decoding of compounds across page boundaries Greg Kroah-Hartman
2013-07-11 22:01 ` [ 16/19] KVM: VMX: mark unusable segment as nonpresent Greg Kroah-Hartman
2013-07-11 22:01 ` [ 17/19] SCSI: sd: Fix parsing of temporary cache mode prefix Greg Kroah-Hartman
2013-07-11 22:01 ` [ 18/19] cpufreq: Fix cpufreq regression after suspend/resume Greg Kroah-Hartman
2013-07-11 22:01 ` [ 19/19] Revert "memcg: avoid dangling reference count in creation failure" Greg Kroah-Hartman
2013-07-11 22:14 ` [ 00/19] 3.10.1-stable review Josh Boyer
2013-07-14 22:54   ` Benjamin Herrenschmidt
2013-07-11 22:29 ` Dave Jones
2013-07-11 22:44   ` Greg Kroah-Hartman
2013-07-12  1:51     ` Steven Rostedt
2013-07-12 14:15     ` Guenter Roeck
2013-07-12 15:22       ` Linus Torvalds
2013-07-12 15:47         ` Steven Rostedt
2013-07-12 15:55           ` Linus Torvalds
2013-07-12 16:17             ` Ingo Molnar
2013-07-12 16:35               ` Josh Boyer
2013-07-12 16:36                 ` Josh Boyer
2013-07-12 17:05                 ` Greg Kroah-Hartman
2013-07-14 22:40                   ` Benjamin Herrenschmidt
2013-07-12 16:48             ` Steven Rostedt
2013-07-12 17:31         ` Guenter Roeck
2013-07-12 17:50           ` Linus Torvalds
2013-07-12 18:11             ` Guenter Roeck
2013-07-12 19:35               ` Theodore Ts'o
2013-07-12 19:49                 ` Steven Rostedt
2013-07-12 19:55                   ` Willy Tarreau
2013-07-12 20:19                   ` Dave Jones
2013-07-12 20:28                     ` Steven Rostedt
2013-07-12 20:31                       ` Steven Rostedt
2013-07-12 21:19                       ` Justin M. Forbes
2013-07-13  0:47                       ` Jochen Striepe
2013-07-13 11:11                         ` Steven Rostedt
2013-07-13 15:10                           ` Dave Jones
2013-07-13 15:54                             ` Steven Rostedt
2013-07-12 19:50             ` Willy Tarreau
2013-07-12 20:47               ` Theodore Ts'o
2013-07-12 21:02                 ` Guenter Roeck
2013-07-13  6:22               ` Greg Kroah-Hartman
2013-07-13  6:36                 ` Willy Tarreau
2013-07-13  6:48                   ` Greg Kroah-Hartman
2013-07-13  7:12                     ` Willy Tarreau
2013-07-15  4:12                       ` Li Zefan
2013-07-15  4:43                         ` Willy Tarreau
2013-07-13 11:42                     ` Theodore Ts'o
2013-07-13 18:27                       ` Greg Kroah-Hartman
2013-07-14  2:22                         ` Theodore Ts'o
2013-07-14  3:51                           ` Greg Kroah-Hartman
2013-07-14  5:24                             ` Guenter Roeck
2013-07-14 20:31                               ` Geert Uytterhoeven
2013-07-13  6:43                 ` Guenter Roeck
2013-07-13  6:58                   ` Greg Kroah-Hartman
2013-07-14 23:52             ` Benjamin Herrenschmidt
2013-07-15  1:40               ` Linus Torvalds
2013-07-15  2:08                 ` Benjamin Herrenschmidt
2013-07-14 22:58     ` Benjamin Herrenschmidt
2013-07-12  0:50 ` When to push bug fixes to mainline Theodore Ts'o
2013-07-12  1:20   ` [Ksummit-2013-discuss] " Nicholas A. Bellinger
2013-07-12  1:54   ` Steven Rostedt
2013-07-12  9:46     ` Jiri Kosina
2013-07-12 11:19       ` Josh Boyer
2013-07-12  2:57   ` John W. Linville
2013-07-12  3:34     ` Greg Kroah-Hartman
2013-07-12  7:32       ` James Bottomley
2013-07-12 17:20       ` H. Peter Anvin
2013-07-12 17:28         ` Greg Kroah-Hartman
2013-07-12 17:50           ` Steven Rostedt
2013-07-12 17:59             ` Linus Torvalds
2013-07-12 18:14               ` Steven Rostedt
2013-07-13 17:52                 ` Geert Uytterhoeven
2013-07-12 17:57           ` Theodore Ts'o
2013-07-12 18:13             ` Guenter Roeck
2013-07-12 18:16             ` H. Peter Anvin
2013-07-12 18:28               ` H. Peter Anvin
2013-07-12 19:44                 ` Linus Torvalds
2013-07-12 19:53                   ` Steven Rostedt
2013-07-12 20:09                     ` Shuah Khan
2013-07-12 20:33                     ` Greg Kroah-Hartman
2013-07-12 20:46                       ` Steven Rostedt
2013-07-12 22:19                       ` H. Peter Anvin
2013-07-12 22:17                     ` H. Peter Anvin
2013-07-13  6:44                   ` Ingo Molnar
2013-07-13  0:24       ` Rafael J. Wysocki
2013-07-13  1:32         ` Greg Kroah-Hartman [this message]
2013-07-13 12:16           ` Rafael J. Wysocki
2013-07-12  3:25   ` Li Zefan
2013-07-15  4:22     ` Rob Landley
2013-07-12  5:14   ` Willy Tarreau
2013-07-16  7:19     ` David Lang
2013-07-16 16:40       ` [Ksummit-2013-discuss] " Takashi Iwai
2013-07-16 16:42         ` David Lang
2013-07-16 19:29           ` Takashi Iwai
2013-07-16 16:59         ` Mark Brown
2013-07-16 17:58           ` Luck, Tony
2013-07-16 18:29             ` Linus Torvalds
2013-07-16 18:41               ` Steven Rostedt
2013-07-16 19:11                 ` Greg Kroah-Hartman
2013-07-16 19:43                   ` Steven Rostedt
2013-07-16 20:10                     ` Willy Tarreau
2013-07-17  2:58                       ` Ben Hutchings
2013-07-17  9:43                       ` Li Zefan
2013-07-16 18:48               ` Willy Tarreau
2013-07-19 10:13               ` Ingo Molnar
2013-07-16 18:39         ` Willy Tarreau
2013-07-16 18:40       ` H. Peter Anvin
2013-07-16 20:29         ` David Lang
2013-07-12 17:11   ` H. Peter Anvin
2013-07-12 17:20 ` [ 00/19] 3.10.1-stable review Shuah Khan
2013-07-12 17:29   ` Greg Kroah-Hartman
2013-07-13  4:14 ` Satoru Takeuchi
2013-07-14 23:06 ` Benjamin Herrenschmidt

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=20130713013211.GA22726@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=ksummit-2013-discuss@lists.linux-foundation.org \
    --cc=ksummit-2013-discuss@lists.linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=rjw@rjwysocki.net \
    --cc=stable@vger.kernel.org \
    --cc=torvalds@linux-foundation.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).