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

On Wed, 2011-02-16 at 15:29 +0100, Stefan Richter wrote:
> On Feb 16 Mike Galbraith wrote:
> > On Wed, 2011-02-16 at 09:55 +0100, Jiri Slaby wrote:
> > > On 02/16/2011 09:25 AM, Ingo Molnar wrote:
> > > > We try to concentrate on regression fixes though.
> > > 
> > > Hi, I cannot fully agree with this. The question is who are "we" here?
> > > If every packager using this stable tree is forced by users/customers to
> > > take it anyway, it's better to have it in stable.
> > > 
> > > It has several reasons:
> > > * It will have an eye of experts on them. Not that at distro providers
> > > there are no experts, but the authors who are cced here know definitely
> > > the code better.
> > > * Not every packager has to duplicate others work.
> > > * The stable tree changes constantly. Managing hundreds of patches
> > > applied to a stable tree before kernels are being packaged is thus
> > > sometimes a hell. Reducing this number is a good thing(TM).
> > 
> > Fully agree on all fronts, but it's a hard call.  When I start auditing,
> > I sweat bullets.  I see piles of bug fixes, and piles of performance
> > enhancements, all of which are ever so tempting, all of which are worthy
> > of backport.. but humans _are_ buggy, so there is risk involved.
> 
> Jiri,
> if the desire is to improve performance of existing features (and maybe
> add this and that little feature that looks attractive), while at the same
> time you want
>   - experts to have looked at these improvements,
>   - packagers to avoid duplicate work,
>   - keep the number of local patches in check,
> then the solution is to /stay close enough to the mainline/.

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.

Just my opinion.  Oh, and critical eye is definitely good, that's why I
posted to stable after all ;-)

	-Mike


  reply	other threads:[~2011-02-17  5:05 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <12978046423644@kroah.org>
2011-02-15 23:02 ` 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 [this message]
2011-02-17  6:22               ` [stable] " Willy Tarreau
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=1297919107.6361.59.camel@marge.simson.net \
    --to=efault@gmx.de \
    --cc=a.p.zijlstra@chello.nl \
    --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

Powered by JetHome