From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-ey0-f174.google.com ([209.85.215.174]:47515 "EHLO mail-ey0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754146Ab2DNPnJ (ORCPT ); Sat, 14 Apr 2012 11:43:09 -0400 MIME-Version: 1.0 In-Reply-To: <20120414054401.GC19802@1wt.eu> References: <20120412144626.GA14868@kroah.com> <20120413105746.10ffb120@stein> <20120413154216.476a02ac@stein> <20120413230525.GA13995@burratino> <20120414054401.GC19802@1wt.eu> Date: Sat, 14 Apr 2012 18:43:06 +0300 Message-ID: (sfid-20120414_174410_270019_30F880C1) Subject: Re: [ 00/78] 3.3.2-stable review From: Felipe Contreras To: Willy Tarreau Cc: Jonathan Nieder , Stefan Richter , Adrian Chadd , 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" Content-Type: text/plain; charset=UTF-8 Sender: linux-wireless-owner@vger.kernel.org List-ID: On Sat, Apr 14, 2012 at 8:44 AM, Willy Tarreau wrote: > Nobody has said it's perfect. Jonathan said it's "close" to perfect. I > personally think it's the best tradeoff we could find between a perfectly > stable branch and a perfect mainline. We manage to converge towards the > best quality in both branches by accepting a small delay in -stable. You are saying the same thing; it cannot be improved. > The problem is that *you* don't accept to wait as soon as you know there's > a bug, I'm going to stop right here. You are making an eloquent argument for something nobody is saying. This is pure straw man argumentation, see the reply from Stefan Richter, who seems to be the only person who is actually following the argument I'm making. > Reverting patches that were not appropriate for -stable happens from > time to time, but only when the issue is specific to -stable (eg: build > issues). Here what you don't seem to understand is that the bug was > not specific to -stable but was present everywhere. So we had a bug > in mainline that we put in -stable, and we want mainline to be fixed > and we use -stable as a guarantee that mainline will be fixed. And it > works and has never failed yet. That's not hard to understand I think. I understand you use 'stable' as guarantee, and I know it works, but do you *need* this guarantee? And before you go on why you need this guarantee to avoid fixes to be lost, this is an *entirely different thing*; we are not talking about fixes in 'stable' that don't exist in mainline--for which there is evidence that those caused problems in the past, we are talking about reverting patches from 'stable' that are not part of the upstream release from where the 'stable' branch was forked--*nobody* has showed any evidence that this has happened before and caused issues. Only Stefan Richter is trying to tackle this argument. Cheers. -- Felipe Contreras From mboxrd@z Thu Jan 1 00:00:00 1970 From: Felipe Contreras Date: Sat, 14 Apr 2012 18:43:06 +0300 Subject: [ath9k-devel] [ 00/78] 3.3.2-stable review In-Reply-To: <20120414054401.GC19802@1wt.eu> References: <20120412144626.GA14868@kroah.com> <20120413105746.10ffb120@stein> <20120413154216.476a02ac@stein> <20120413230525.GA13995@burratino> <20120414054401.GC19802@1wt.eu> 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 Sat, Apr 14, 2012 at 8:44 AM, Willy Tarreau wrote: > Nobody has said it's perfect. Jonathan said it's "close" to perfect. I > personally think it's the best tradeoff we could find between a perfectly > stable branch and a perfect mainline. We manage to converge towards the > best quality in both branches by accepting a small delay in -stable. You are saying the same thing; it cannot be improved. > The problem is that *you* don't accept to wait as soon as you know there's > a bug, I'm going to stop right here. You are making an eloquent argument for something nobody is saying. This is pure straw man argumentation, see the reply from Stefan Richter, who seems to be the only person who is actually following the argument I'm making. > Reverting patches that were not appropriate for -stable happens from > time to time, but only when the issue is specific to -stable (eg: build > issues). Here what you don't seem to understand is that the bug was > not specific to -stable but was present everywhere. So we had a bug > in mainline that we put in -stable, and we want mainline to be fixed > and we use -stable as a guarantee that mainline will be fixed. And it > works and has never failed yet. That's not hard to understand I think. I understand you use 'stable' as guarantee, and I know it works, but do you *need* this guarantee? And before you go on why you need this guarantee to avoid fixes to be lost, this is an *entirely different thing*; we are not talking about fixes in 'stable' that don't exist in mainline--for which there is evidence that those caused problems in the past, we are talking about reverting patches from 'stable' that are not part of the upstream release from where the 'stable' branch was forked--*nobody* has showed any evidence that this has happened before and caused issues. Only Stefan Richter is trying to tackle this argument. Cheers. -- Felipe Contreras