Return-path: Received: from einhorn.in-berlin.de ([192.109.42.8]:60054 "EHLO einhorn.in-berlin.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751114Ab2DNJLO convert rfc822-to-8bit (ORCPT ); Sat, 14 Apr 2012 05:11:14 -0400 Date: Sat, 14 Apr 2012 11:10:44 +0200 From: Stefan Richter To: Felipe Contreras Cc: Jonathan Nieder , 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" Subject: Re: [ 00/78] 3.3.2-stable review Message-ID: <20120414111044.4930a5f3@stein> (sfid-20120414_111216_039419_25EAF739) In-Reply-To: References: <20120412011313.GA23764@kroah.com> <20120412144626.GA14868@kroah.com> <20120413105746.10ffb120@stein> <20120413154216.476a02ac@stein> <20120413230525.GA13995@burratino> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-wireless-owner@vger.kernel.org List-ID: On Apr 14 Felipe Contreras wrote: > On Sat, Apr 14, 2012 at 2:05 AM, Jonathan Nieder wrote: > > I don't think Stefan meant the above as tongue-in-cheek, for what it's > > worth.  Another stable kernel with different rules really would be an > > interesting exercise, and would probably fulfill a need for a certain > > audience. > > > > It's not like nobody does that already, anyway.  For example, I hear > > Fedora has a kernel that they maintain well for a different audience, > > using different rules. > > Of course, although the difference with the stable kernel would be > very small if the only thing added is an extra rule for acceptance: > "It reverts an earlier > patch to 'stable'." It looks like a small difference on the surface, but it isn't. It would mean "yes, we /do/ forward ports in -stable too in some cases". In face of the frequent and predictable rate of mainline releases and the very frequent stable releases, the problems associated with forward ports very much appear to outweigh the benefits. So the folks who do the actual work appear to be content with stable = backports only, and it seems you can't convince them to do forward ports. Which means that if you really want forward ports, you need to find somebody else who does forward ports (e.g. a suitable distributor) or do them yourself. > But "we do this, and if you don't like it you can do whatever you > want" is not a valid argument in favor of the status quo, That would not be a valid argument, no. But it has been mentioned /why/ only backports are done in stable, i.e. what the problems with forward ports are: - First of all more work. (Could be compensated by longer periods between stable releases, which would be an obvious downside too, and actually defeat much of the purpose of the stable series of getting out fixes to people.) - Backports are already risky, which is why only /small/ backports are allowed into stable. Forward ports bring their own set of risks. Inevitably, users of the kernel called "stable" will get even more reason to wonder why this series is not "stable" in a sense of "absolutely free of regressions". For example, merging subsystem development trees into the mainline is actually a forward port. The mainline is at risk not only because that subsystem tree hasn't had as much exposure to hardware and workloads as the mainline will have, but additionally because the merge result is different from the subsystem tree head. (The result is a forward port.) Mainline development uses for example the linux-next tree in order to reduce a subset of these forward porting risks, those associated with conflicting developments in different subsystems and cross-tree development. Which kinds of tools should stable use if it were to accept forward ports? So, rather than managing the risk of forward ports in stable, those risks are systematically avoided by not ever doing forward ports, not even small ones. - The mainline would not immediately benefit from the work put into forward ports in stable. Worse, fixes in those forward ports might not ever make it into the mainline. That would be detrimental to all mainline users, and thus to all stable users. (Stable users are mainline users because stable is branched off of mainline every 2.5 months.) These downsides have been mentioned in the thread; please consider them. It is not about "we¹ do this because we are set in our ways". The stable rules have pragmatic reasons which are for example founded on lessons learned from the 2.4/2.5/2.6 history of development, maintenance, and distribution. So there are arguments for the status quo, the arguments have been mentioned several times, and I can't see what would invalidate any of these arguments. -------- ¹) Greg, if you are still reading this thread: Excuse the 'we', I do not mean to speak for you. Besides, Greg, thank you for the work. As a driver maintainer and when supporting end users, I benefit from it since distributor kernels do not deviate much from mainline these days, among else thanks to your stable and longterm series. And it is an important way for me to get certain driver fixes delivered to users conveniently and timely. -- Stefan Richter -=====-===-- -=-- -===- http://arcgraph.de/sr/