Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261748AbVCCJSc (ORCPT ); Thu, 3 Mar 2005 04:18:32 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261679AbVCCJRu (ORCPT ); Thu, 3 Mar 2005 04:17:50 -0500 Received: from parcelfarce.linux.theplanet.co.uk ([195.92.249.252]:11404 "EHLO parcelfarce.linux.theplanet.co.uk") by vger.kernel.org with ESMTP id S261748AbVCCJOr (ORCPT ); Thu, 3 Mar 2005 04:14:47 -0500 Message-ID: <4226D571.6040406@pobox.com> Date: Thu, 03 Mar 2005 04:14:25 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Greg KH CC: "David S. Miller" , torvalds@osdl.org, akpm@osdl.org, linux-kernel@vger.kernel.org Subject: Re: RFD: Kernel release numbering References: <422674A4.9080209@pobox.com> <42268749.4010504@pobox.com> <20050302200214.3e4f0015.davem@davemloft.net> <42268F93.6060504@pobox.com> <4226969E.5020101@pobox.com> <20050302205826.523b9144.davem@davemloft.net> <4226C235.1070609@pobox.com> <20050303080459.GA29235@kroah.com> <4226CA7E.4090905@pobox.com> <20050303085806.GB29955@kroah.com> In-Reply-To: <20050303085806.GB29955@kroah.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3797 Lines: 106 Greg KH wrote: > On Thu, Mar 03, 2005 at 03:27:42AM -0500, Jeff Garzik wrote: > >>Greg KH wrote: >> >>>Sure they've been asking for it, but I think they really don't know what >>>it entails. Look at all of the "non-stable" type patches in the -ac and >>>as tree. There's a lot of stuff in there. It's a slippery slope down >>>when trying to say, "I'm only going to accept bug fixes." >> >>We have all these problems precisely because _nobody_ is saying "I'm >>only going to accept bug fixes". We _need_ some amount of release >>engineering. Right now we basically have none. > > > Linus says that in -rc releases, are you not paying attention to that? > (yes, I know you are...) The point there is that users, who are conditioned in the software world to think "release candidate means bug fixes only" come to Linux only to learn that -rc1 isn't a release candidate, it's just the first public test kernel. -rc2 isn't a release candidate, it's just a signal to kernel developers to slow down -rc3 may be a release candidate, unless Linus does something typical and merges non-bug fixes. -rc4 is probably a release candidate ... The users ARE paying attention to this -- this is precisely why they do not take -rc releases seriously. >>>Bug fixes for what? Kernel api changes that fix bugs? That's pretty >>>big. Some driver fixes, but not others? Driver fixes that are in the >>>middle of bigger, subsystem reworks as a series of patches? All of this >>>currently happens today in the main tree in a semi-cohesive manner. To >>>try to split it out is a very difficult task. >> >>Easiest to answer with a concrete example: >> >>Linux 2.6.11 is released. Linus then does a >> bk clone linux-2.6 linux-2.6.11 >> >>Bug fixes that >>(a) 2.6.11 users really should have, or >>(b) Linus/Andrew feels are important, or >>(c) a subsystem maintainer feels are important [and does the work to >>split out the fixes] >> >>go into linux-2.6.11 repo, and then is pulled into linux-2.6 repo. >> >>All other changes go into linux-2.6. >> >>There's no need to over-think or over-work this. The goal is to provide >>a stable 2.6.11 for users, until 2.6.12 is available. > > > Will Linus start accepting 2.6.12 patches right after 2.6.10 is out? > > >>My prediction is that several patches will flow into the linux-2.6.11 >>repo a week or so after a release, and then the flow will die off to a >>trickle. Subsystem maintainers that care can submit patches/BK-pulls >>for the stable release if they so desire. >> >>Only important "oh shit, that should have been in 2.6.11" bug fixes need >>apply. Bug fixes for reworks, API changes, etc. are -not- applicable to >>linux-2.6.11 repo. >> >>Since BitKeeper can handle nicely a >> cd linux-2.6 >> bk pull ../linux-2.6.11 >>there is no duplication of bug fixes. > > > That sounds very sane to me, I can live with it. > > The main point is, will people really test the 2.6.odd releases to help > us out in making this new scheme work. If so, I'm all for it. 2.6.X.Y is a bit different from 2.6.{odd|even}. With 2.6.X.Y, you are not limited to single bugfix release. With 2.6.X.Y, the kernel only gets successively more stable and bugfixed, without having to worry about new breakages. With 2.6.X.Y, you are giving the users a familiar paradigm for understanding the release mechanism. With 2.6.X.Y, all releases are "real releases." You're not tricking the users with semantic games. So there is a strong incentive not only to test... but to _use_ our releases. Jeff - 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/