From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-ee0-f46.google.com ([74.125.83.46]:35413 "EHLO mail-ee0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966124Ab2DLW3s (ORCPT ); Thu, 12 Apr 2012 18:29:48 -0400 MIME-Version: 1.0 In-Reply-To: References: <20120411231102.GA6404@kroah.com> <20120412002927.GA23167@kroah.com> <20120412011313.GA23764@kroah.com> <20120412144626.GA14868@kroah.com> Date: Fri, 13 Apr 2012 01:29:46 +0300 Message-ID: (sfid-20120413_003007_333057_1509BCB4) Subject: Re: [ 00/78] 3.3.2-stable review From: Felipe Contreras To: Linus Torvalds Cc: 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" Content-Type: text/plain; charset=UTF-8 Sender: linux-wireless-owner@vger.kernel.org List-ID: 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. -- Felipe Contreras From mboxrd@z Thu Jan 1 00:00:00 1970 From: Felipe Contreras Date: Fri, 13 Apr 2012 01:29:46 +0300 Subject: [ath9k-devel] [ 00/78] 3.3.2-stable review In-Reply-To: References: <20120411231102.GA6404@kroah.com> <20120412002927.GA23167@kroah.com> <20120412011313.GA23764@kroah.com> <20120412144626.GA14868@kroah.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org 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. -- Felipe Contreras