Re: [ 00/78] 3.3.2-stable review

[Jesper Juhl]

On Fri, 13 Apr 2012, Felipe Contreras wrote:

> On Thu, Apr 12, 2012 at 10:05 PM, Linus Torvalds
> <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> > On Thu, Apr 12, 2012 at 9:49 AM, Felipe Contreras
> > <felipe.contreras@xxxxxxxxx> wrote:
> >>>
> >>> A revert is the same as a patch. ÂIt needs to be in Linus's tree before
> >>> I can add it to the stable releases.
> >>
> >> Right, because otherwise people's systems would actually work.
> >
> > There are rules for a damn good reason.
> >
> > The rule for -stable is that the changes *have* to be in upstream, for
> > a very simple reason: otherwise bugs get re-introduced.
> >
> > If -stable starts revertign things that aren't reverted up-stream,
> > what do you think happens to the *next* kernel version?
> 
> Which is why nobody is trying to change the rules regarding that.
> 
> And your same argument applies to the all the thousands of commits on
> the next kernel version; what would happen on the next kernel version?
> 
> The relevant patch, like the thousands of patches in v3.4-rc*, did not
> exist in v3.3, so if you add one on v3.3.1, and remove it on v3.3.2
> would be *exactly* the same as if you had not added it at all to the
> stable series.
> 
> > I don't think you realize how well kernel development has worked over
> > the last few years. And the stable rules are part of it.
> 
> I do understand how well the development works, which is why I often
> use it as an example and guideline, but that doesn't mean it's
> perfect.
> 
> > So stop complaining. Reverts really *are* just patches, Greg is 100%
> > right, and you are simply wrong.
> 
> I could argue in favor of exceptions, but I don't think you realize
> the fact that this change does not affect your tree *at all*. Adding
> and removing a patch in the stable tree is a no-op.
> 
> > And the revert is now apparently in John's tree, and will make it to
> > David and then me shortly. It will get reverted in stable too once
> > that happens. In the meantime, your complaints are Âto Greg only shows
> > that you don't understand why the rules exist, and the fact that you
> > *continue* to complain just makes you look stupid.
> 
> Is that going to happen before Friday? If not, then v3.3.2 will still
> be broken *for no reason*.
> 
> 

Ok, -stable got broken because a bad patch was backported from mainline to 
stable - obviously that's not good.

But, just reverting that broken patch from stable is *not* good enough. 
Then we still have a broken mainline.

The rule that only commits which are in mainline get applied to -stable 
makes really, Really, REALLY good sense. It helps ensure that we don't 
miss fixes going forward.

Imagine that bad patch xyz got added to mainline and backported to stable 
and that the only people that get bitten by it are conservative types that 
only run -stable kernels. Then we revert the patch from stable since it 
broke stuff and now everyone are happy - but *mainline is still broken* 
and there's noone pushing for the problem to get fixed in mainline since 
noone affected by the problem run that kernel :-(

By insisting that only patches in mainline get backported to -stable we 
ensure that both mainline and stable get fixed (and thus also the *next* 
stable kernel that'll be cut from mainline in the future).

Yes it's a pain that -stable has to suffer a broken commit for a while - 
but sometimes that's just the little pain you have to accept. The greater 
good is that with the current rules both mainline, current -stable and 
future -stable will get fixed.

-- 
Jesper Juhl <jj@xxxxxxxxxxxxx>       http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.