public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: Mike Galbraith <efault@gmx.de>
Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>,
	Jiri Slaby <jirislaby@gmail.com>,
	gregkh@suse.de, LKML <linux-kernel@vger.kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	srostedt <srostedt@redhat.com>,
	stable-commits@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
	ghaskins@novell.com, stable@kernel.org, a.p.zijlstra@chello.nl
Subject: Re: [stable] Patch "sched: Give CPU bound RT tasks preference" has been added to the 2.6.32-longterm tree
Date: Thu, 17 Feb 2011 07:22:28 +0100	[thread overview]
Message-ID: <20110217062228.GA5890@1wt.eu> (raw)
In-Reply-To: <1297919107.6361.59.camel@marge.simson.net>

Hi Mike,

On Thu, Feb 17, 2011 at 06:05:07AM +0100, Mike Galbraith wrote:
> That's the intent of pushing more than _purely_ critical bugfixes, get a
> bit closer.  Enterprise can't move as fast as mainline, not even close,
> that's a given.  Stable problem get griped about though, so there's no
> choice but to take some risk.  The tricky bit is how much, and how you
> go about it.
> 
> People are fixing this and that in their enterprise kernels privately
> every day.  The only difference between that, and pushing baked fixes
> back is that pushing to stable is visible.  I strongly suspect that
> there are just tons of mainline backports sitting in each and every
> enterprise tree in existence.  They could have been pushed to stable,
> with _less_ stability risk, due to the higher visibility.

I can confirm that my local 2.6.27 tree has had a quite number of sched
updates that were posted by Ingo, Peter or You in the last two years,
and I'll definitely be considering your work for future updates. However
we must be very careful about what we include in -stable. Its primary
purpose precisely is to let every user upgrade without checking what was
merged because we are responsible for ensuring there is no regression. I
would say it's already a bit late in the 2.6.32 cycle for that but we're
in the first half of its lifecycle and it has a lot of users, so that
would still benefit a lot of people. Let's just hope it will not break
any workload (eg: double the time it takes for a specific task) otherwise
-stable and -longterm will lose some trust among enterprise users.

Ideally we should just make a stable release with just enhancements
from time to time, without important fixes so that people can revert
to the previous one and alert us in case of trouble. But my feeling
is that the current version more or less matches that goal, I don't
remember having seen anything really critical in it that can't be
reverted in case of trouble.

So let's have it, tell users to report any issue and move on :-)

Regards,
Willy


  reply	other threads:[~2011-02-17  6:23 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <12978046423644@kroah.org>
2011-02-15 23:02 ` Patch "sched: Give CPU bound RT tasks preference" has been added to the 2.6.32-longterm tree Steven Rostedt
2011-02-15 23:32   ` Greg KH
2011-02-16  2:46     ` Mike Galbraith
2011-02-16  2:01   ` Mike Galbraith
2011-02-16  2:03     ` Steven Rostedt
2011-02-16  8:25     ` Ingo Molnar
2011-02-16  8:55       ` Jiri Slaby
2011-02-16  9:22         ` Ingo Molnar
2011-02-16  9:45         ` Mike Galbraith
2011-02-16 14:29           ` Stefan Richter
2011-02-17  5:05             ` Mike Galbraith
2011-02-17  6:22               ` Willy Tarreau [this message]
2011-02-17  7:52               ` Stefan Richter
2011-02-17  9:41                 ` Mike Galbraith
2011-02-17 14:28                   ` Stefan Richter

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=20110217062228.GA5890@1wt.eu \
    --to=w@1wt.eu \
    --cc=a.p.zijlstra@chello.nl \
    --cc=efault@gmx.de \
    --cc=ghaskins@novell.com \
    --cc=gregkh@suse.de \
    --cc=jirislaby@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rostedt@goodmis.org \
    --cc=srostedt@redhat.com \
    --cc=stable-commits@vger.kernel.org \
    --cc=stable@kernel.org \
    --cc=stefanr@s5r6.in-berlin.de \
    /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