From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from 1wt.eu ([62.212.114.60]:65068 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752808Ab2DLS5j (ORCPT ); Thu, 12 Apr 2012 14:57:39 -0400 Date: Thu, 12 Apr 2012 20:40:58 +0200 From: Willy Tarreau To: Felipe Contreras Cc: Greg KH , Sergio Correia , linux-kernel@vger.kernel.org, stable@vger.kernel.org, torvalds@linux-foundation.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: <20120412184058.GO8203@1wt.eu> (sfid-20120412_205743_143785_440577EA) References: <20120411231102.GA6404@kroah.com> <20120412002927.GA23167@kroah.com> <20120412011313.GA23764@kroah.com> <20120412144626.GA14868@kroah.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 In-Reply-To: Sender: linux-wireless-owner@vger.kernel.org List-ID: On Thu, Apr 12, 2012 at 07:49:34PM +0300, Felipe Contreras wrote: > On Thu, Apr 12, 2012 at 5:46 PM, Greg KH wrote: > > A revert is the same as a patch.  It needs to be in Linus's tree before > > I can add it to the stable releases. > > Right, because otherwise people's systems would actually work. > > But hey, as I said, following rules is more important, regardless of > what the rules are, and why they are there. The rules that actually > triggered this issue in v3.3.1, as this is not in v3.3. > > You could just accept that the patch should have never landed in > v3.3.1 in the first place, but it's much easier to arbitrarily keep > stacking patches without thinking too much about them. > > I guess I'll better use Linus's releases for now and go to v3.3. Felipe, you're unfair to Greg. You're saying this because you don't know what it's like to be on the side of the guy who has to decide whether to apply a patch or not, which basically means whether to risk breaking systems or to leave broken systems as they are. Most stable users will switch from a stable version to another one in a next release, and these users do not want any regression. This means that we absolutely don't want to risk that a stable version has a fix that is missing from a newer version. Yes this is a crappy and annoying process but it's the only way to ensure that fixes don't get lost during an upgrade. BTW, it works because if we're discussing this here, it's because this final fix or revert appears to be missing from mainline. After the discussion I'm sure it will be there. Last point is that stable maintainers are not your slaves. If you know how to patch your mainline kernel to apply a stable patch, you also know how to apply the patch you're pointing to. It's quite easy and many of us do that. *All* the kernels I'm using are stable + a few local patches and I don't see where the problem is. So please be a bit more constructive. Make your job by ensuring that the fix you want is in mainline then pass the commit ID to Greg so that he can merge it in next release. You'll feel relieved and everyone will be glad to benefit from this fix. Willy From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Thu, 12 Apr 2012 20:40:58 +0200 From: Willy Tarreau To: Felipe Contreras Cc: Greg KH , Sergio Correia , linux-kernel@vger.kernel.org, stable@vger.kernel.org, torvalds@linux-foundation.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: <20120412184058.GO8203@1wt.eu> References: <20120411231102.GA6404@kroah.com> <20120412002927.GA23167@kroah.com> <20120412011313.GA23764@kroah.com> <20120412144626.GA14868@kroah.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-ID: On Thu, Apr 12, 2012 at 07:49:34PM +0300, Felipe Contreras wrote: > On Thu, Apr 12, 2012 at 5:46 PM, Greg KH wrote: > > A revert is the same as a patch. �It needs to be in Linus's tree before > > I can add it to the stable releases. > > Right, because otherwise people's systems would actually work. > > But hey, as I said, following rules is more important, regardless of > what the rules are, and why they are there. The rules that actually > triggered this issue in v3.3.1, as this is not in v3.3. > > You could just accept that the patch should have never landed in > v3.3.1 in the first place, but it's much easier to arbitrarily keep > stacking patches without thinking too much about them. > > I guess I'll better use Linus's releases for now and go to v3.3. Felipe, you're unfair to Greg. You're saying this because you don't know what it's like to be on the side of the guy who has to decide whether to apply a patch or not, which basically means whether to risk breaking systems or to leave broken systems as they are. Most stable users will switch from a stable version to another one in a next release, and these users do not want any regression. This means that we absolutely don't want to risk that a stable version has a fix that is missing from a newer version. Yes this is a crappy and annoying process but it's the only way to ensure that fixes don't get lost during an upgrade. BTW, it works because if we're discussing this here, it's because this final fix or revert appears to be missing from mainline. After the discussion I'm sure it will be there. Last point is that stable maintainers are not your slaves. If you know how to patch your mainline kernel to apply a stable patch, you also know how to apply the patch you're pointing to. It's quite easy and many of us do that. *All* the kernels I'm using are stable + a few local patches and I don't see where the problem is. So please be a bit more constructive. Make your job by ensuring that the fix you want is in mainline then pass the commit ID to Greg so that he can merge it in next release. You'll feel relieved and everyone will be glad to benefit from this fix. Willy From mboxrd@z Thu Jan 1 00:00:00 1970 From: Willy Tarreau Date: Thu, 12 Apr 2012 20:40:58 +0200 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: <20120412184058.GO8203@1wt.eu> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org On Thu, Apr 12, 2012 at 07:49:34PM +0300, Felipe Contreras wrote: > On Thu, Apr 12, 2012 at 5:46 PM, Greg KH wrote: > > A revert is the same as a patch. ?It needs to be in Linus's tree before > > I can add it to the stable releases. > > Right, because otherwise people's systems would actually work. > > But hey, as I said, following rules is more important, regardless of > what the rules are, and why they are there. The rules that actually > triggered this issue in v3.3.1, as this is not in v3.3. > > You could just accept that the patch should have never landed in > v3.3.1 in the first place, but it's much easier to arbitrarily keep > stacking patches without thinking too much about them. > > I guess I'll better use Linus's releases for now and go to v3.3. Felipe, you're unfair to Greg. You're saying this because you don't know what it's like to be on the side of the guy who has to decide whether to apply a patch or not, which basically means whether to risk breaking systems or to leave broken systems as they are. Most stable users will switch from a stable version to another one in a next release, and these users do not want any regression. This means that we absolutely don't want to risk that a stable version has a fix that is missing from a newer version. Yes this is a crappy and annoying process but it's the only way to ensure that fixes don't get lost during an upgrade. BTW, it works because if we're discussing this here, it's because this final fix or revert appears to be missing from mainline. After the discussion I'm sure it will be there. Last point is that stable maintainers are not your slaves. If you know how to patch your mainline kernel to apply a stable patch, you also know how to apply the patch you're pointing to. It's quite easy and many of us do that. *All* the kernels I'm using are stable + a few local patches and I don't see where the problem is. So please be a bit more constructive. Make your job by ensuring that the fix you want is in mainline then pass the commit ID to Greg so that he can merge it in next release. You'll feel relieved and everyone will be glad to benefit from this fix. Willy