public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: Mike Galbraith <efault@gmx.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: Wed, 16 Feb 2011 15:29:06 +0100	[thread overview]
Message-ID: <20110216152906.75d4000c@stein> (raw)
In-Reply-To: <1297849553.5275.29.camel@marge.simson.net>

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/.

Unstable -longterm trees (unstable as in having a high rate of changes,
possibly as in having frequent regressions) are for sure an alternative
solution that those who use these trees apparently do consider.  But if
regressions avoidance is not their top priority, what other reason do they
have to follow -longterm instead of the mainline?

(Says a mainline user, and a driver maintainer who has pushed his share of
occasional regressions to -stable branches but hopes to constantly get
better at regression avoidance.)
-- 
Stefan Richter
-=====-==-== --=- =----
http://arcgraph.de/sr/

  reply	other threads:[~2011-02-16 14:30 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 [this message]
2011-02-17  5:05             ` Mike Galbraith
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=20110216152906.75d4000c@stein \
    --to=stefanr@s5r6.in-berlin.de \
    --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 \
    /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