* 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-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
