Re: [ 00/78] 3.3.2-stable review

[Ingo Molnar]

* Felipe Contreras <felipe.contreras@xxxxxxxxx> wrote:

> On Fri, Apr 13, 2012 at 1:07 AM, Linus Torvalds
> <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> > On Thu, Apr 12, 2012 at 3:04 PM, Felipe Contreras
> > <felipe.contreras@xxxxxxxxx> wrote:
> >>
> >> Sure, but removing that patch from the stable tree is not 
> >> going the change that information; we already know the 
> >> patch is wrong.
> >
> > .. and we wait until it has been fixed in mainline so that 
> > we *know* that information doesn't get lost.
> 
> So why don't we pick potentially dangerous patches that might 
> benefit from some testing, put them in 'stable', and if there 
> are problems, make sure they get fixed in upstream first?
>
> Or for that matter totally broken patches we want to make sure 
> they get fixed in upstream.
> 
> Because the priority of the 'stable' tree is *stability*. Is 
> it not?
> 
> But what you are saying is: *before* the final review, even a 
> hint that the patch might cause problems is reason enough to 
> drop it from stable, but *after* the review, if we know the 
> patch is totally broken, then it's the opposite; we really 
> want it in.

What you don't seem to understand is that there are good reasons 
why we first fix bugs upstream, then in -stable. Greg explained 
it to you, Linus explained it to you and so did many others.

Having an order of patches *necessarily* means that the 
development tree will get fixes sooner than the stable tree. In 
other words, this *necessarily* means that the stable tree - and 
its users - will have to wait a little bit more to have the fix. 
In the worst-case this 'have to wait a little bit longer' might 
span the time between two minor stable kernel releases.

You seem to equate this 'have to wait a little bit longer to get 
the fix' property of the maintenance model with 'we don't care 
about stable tree users' - that claim is obviously idiotic and 
most of your arguments in this thread are idiotic as well.

Thanks,

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