On Wed, Feb 16, 2011 at 09:30:25AM +0100, Ingo Molnar wrote: > > * Mike Galbraith <[email protected]> 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 <[email protected]> > > > > > > > > commit 618765801ebc271fe0ba3eca99fcfd62a1f786e1 upstream. > > > > > > > > This was left over from "7c9414385e sched: Remove USER_SCHED" > > > > > > > > Signed-off-by: Dan Carpenter <[email protected]> > > > > > > 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 _______________________________________________ stable mailing list [email protected] http://linux.kernel.org/mailman/listinfo/stable
