Re: [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Sat, Apr 14, 2012 at 1:47 PM, Ingo Molnar <mingo@xxxxxxxxxx> wrote:
>
> * 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.

This is a straw man again. Again; we are not talking about fixes in
'stable' that don't exist in mainline, we are talking about reverting
patches from 'stable' that are not part of the upstream release from
where the 'stable' branch was forked.

You are avoiding the argument you replying to; yesterday a patch was
droppable from the stable review queue, but today, after the release,
now we *need* it to stay there until it's fixed in the mainline. What
changed?

What makes a patch droppable yesterday, but dependent on mainline today?

-- 
Felipe Contreras
--
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/