Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756146Ab1FHORV (ORCPT ); Wed, 8 Jun 2011 10:17:21 -0400 Received: from mail-fx0-f46.google.com ([209.85.161.46]:57702 "EHLO mail-fx0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754916Ab1FHORU convert rfc822-to-8bit (ORCPT ); Wed, 8 Jun 2011 10:17:20 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type :content-transfer-encoding; b=RO+DXk2aCl0Gx0eiYhbH9b07Kxfjyp/Jli0moHWOo0zxOHb3wpjtMBwO6QO5ibyARN RHPhpjHMrDVZmenvq1nwzvIFfKQ8z9fBx26tUMqAqwhwCKVFRq0BHumqfmXDXRMw4Djk HwJSFiv+AC8Ik1+8zH1EO3xiAxcOvi64Uei+c= MIME-Version: 1.0 In-Reply-To: <20110608133833.GD30037@thunk.org> References: <4DEE1D96.6020208@profihost.ag> <6D8DA3D2-D90B-4D82-BDC9-C3F0264A68BF@mit.edu> <4DEE2C70.8060301@profihost.ag> <4DEE9EDA.90001@profihost.ag> <20110608133833.GD30037@thunk.org> From: Mike Snitzer Date: Wed, 8 Jun 2011 10:16:59 -0400 X-Google-Sender-Auth: xo8cPgKSQ3u6Wh1nIkJoWW4SxS0 Message-ID: Subject: Re: XFS problem in 2.6.32 To: "Ted Ts'o" , John Kacur , Stefan Priebe - Profihost AG , david@lang.hm, linux-kernel@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2757 Lines: 62 Ted, On Wed, Jun 8, 2011 at 9:38 AM, Ted Ts'o wrote: > On Wed, Jun 08, 2011 at 10:00:39AM +0200, John Kacur wrote: > >> Ok, I don't speak for my company, and your point about not expecting >> people to do this work for you is valid, however I don't see why you >> need to take potshots at Red Hat > > It wasn't a potshot; if it is true, it is a completely rational > economic argument that is completely within the bounds of the > requirements of the GPL, and with LKML community standards. > > The reason why I say it is because of (a) http://lwn.net/Articles/430098/, > and (b) a few months ago, when I quietly floated starting a new > long-term stable kernel series that a number of companies would > maintain cooperatively, I was told, privately, that such a proposal > would not likely be received positively by Red Hat management because > of the reasons behind the policy instituted by (a). OK, you seem to think you have it all figured out and that your Red Hat contact knows everything there is to the Red Hat kernel engineering development process. However, it doesn't jive with what I know or how I (and my coworkers) work on a daily basis. Since we're referencing lwn.net articles please have a look at these comments that I previously made on this subject of RHEL and stable@: http://lwn.net/Articles/431317/ http://lwn.net/Articles/431420/ >> I'm not even claiming that these are typical stats, but as just a >> quick check on your statement, the contributions for one stable >> release are in the same ballpark as everyone else. > > Nah, that just means that commits which are labelled with "CC: > stable@vger.kernel.org" are automatically accepted into stable kernel > series. > > If you can point efforts where painful backports of ext4 and xfs bug > fixes into RHEL 6.x are making it back into 2.6.32.y, even though in > some cases it takes tens of hours of engineering and QA efforts, we > can talk. ?But please note that I wasn't calling out Red Hat as being > bad or evil by doing what they are doing; it is completely > economically rational and allowed by the GPL rules for them to be > doing what they are doing. ?(Just as what Android has been doing with > their constant forward porting of the Wakelocks API is completely > within the GPL rules.) And what _exactly_ is Red Hat (not) doing? Red Hat isn't going crazy backporting its upstream > 2.6.32 fixes to 2.6.32.y even when Red Hat doesn't consume 2.6.32.y? *gasp* Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/