From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-wg0-f44.google.com ([74.125.82.44]:61466 "EHLO mail-wg0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753784Ab2DNKrj (ORCPT ); Sat, 14 Apr 2012 06:47:39 -0400 Date: Sat, 14 Apr 2012 12:47:33 +0200 From: Ingo Molnar To: Felipe Contreras Cc: Linus Torvalds , Greg KH , Sergio Correia , linux-kernel@vger.kernel.org, stable@vger.kernel.org, akpm@linux-foundation.org, alan@lxorguk.ukuu.org.uk, linux-wireless Mailing List , Sujith Manoharan , "ath9k-devel@lists.ath9k.org" , "John W. Linville" Subject: Re: [ 00/78] 3.3.2-stable review Message-ID: <20120414104733.GA4871@gmail.com> (sfid-20120414_124757_555115_ADDB6095) References: <20120412011313.GA23764@kroah.com> <20120412144626.GA14868@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: Sender: linux-wireless-owner@vger.kernel.org List-ID: * Felipe Contreras wrote: > On Fri, Apr 13, 2012 at 1:07 AM, Linus Torvalds > wrote: > > On Thu, Apr 12, 2012 at 3:04 PM, Felipe Contreras > > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Date: Sat, 14 Apr 2012 12:47:33 +0200 Subject: [ath9k-devel] [ 00/78] 3.3.2-stable review In-Reply-To: References: <20120412011313.GA23764@kroah.com> <20120412144626.GA14868@kroah.com> Message-ID: <20120414104733.GA4871@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org * Felipe Contreras wrote: > On Fri, Apr 13, 2012 at 1:07 AM, Linus Torvalds > wrote: > > On Thu, Apr 12, 2012 at 3:04 PM, Felipe Contreras > > 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