Re: [Stable-review] [114/115] sched: Remove some dead code

[Willy Tarreau]

On Wed, Feb 16, 2011 at 09:30:25AM +0100, Ingo Molnar wrote:
> 
> * Mike Galbraith <efault@xxxxxx> wrote:
> 
> > On Wed, 2011-02-16 at 10:37 +0300, Dan Carpenter wrote:
> > > On Tue, Feb 15, 2011 at 05:46:20PM -0800, Greg KH wrote:
> > > > 2.6.32-longterm review patch.  If anyone has any objections, please let us know.
> > > > 
> > > > ------------------
> > > > 
> > > > 
> > > > From: Dan Carpenter <error27@xxxxxxxxx>
> > > > 
> > > > commit 618765801ebc271fe0ba3eca99fcfd62a1f786e1 upstream.
> > > > 
> > > > This was left over from "7c9414385e sched: Remove USER_SCHED"
> > > > 
> > > > Signed-off-by: Dan Carpenter <error27@xxxxxxxxx>
> > > 
> > > This is just a cleanup patch.  It doesn't really warrant backporting.
> > 
> > There's no reason to leave the dirt lying about though.
> 
> That's not the threshold for -stable backporting though.
> 
> A patch is eligible for -stable if and only if it's eligible for sending it to Linus 
> via tip:sched/urgent as well: i.e. important bugfix or fresh regression.
> 
> Now, a cleanup patch might still be eligible to be sent to Linus if for some reason 
> it's absolutely required for a fix - but in general we do not backport them.
> 
> The risk to -stable is obvious: instead of having a well-known .32 scheduler we have 
> this morphing code that no-one has really tested in that form.
> 
> So while i dont mind the series you sent, please lets be *much* more careful with 
> -stable backports in the future. Rule #1: if you ever have to ask yourself whether a 
> patch is -stable eligible it probably isnt.

Sometimes cleanup patches make the work easier for stable maintainers because
further patches apply without conflicts. It happened to me from time to time
in the past to merge such patches because I got bored of systematically having
to manually apply patches. But I agree with you that generally we should avoid
to merge such patches.

In my opinion the right question to ask oneself about the eligibility of a
patch is how you'd justify it to your end users. If you can justify it by
an improvement they can perceive (reliability, security, speed) then it may
be worth it. If it's just "that code was not used anymore", they'll start
to lose trust.

Regards,
Willy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/