From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Fri, 8 Jul 2016 17:43:52 -0700 From: Dmitry Torokhov To: "Rafael J. Wysocki" Message-ID: <20160709004352.GK28589@dtor-ws> References: <5780334E.8020801@roeck-us.net> <20160709001046.GH28589@dtor-ws> <91774112.AKkGksYjl6@vostro.rjw.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <91774112.AKkGksYjl6@vostro.rjw.lan> Cc: ksummit-discuss@lists.linux-foundation.org, ksummit-discuss@lists.linuxfoundation.org Subject: Re: [Ksummit-discuss] [CORE TOPIC] stable workflow List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Sat, Jul 09, 2016 at 02:37:40AM +0200, Rafael J. Wysocki wrote: > On Friday, July 08, 2016 05:10:46 PM Dmitry Torokhov wrote: > > On Fri, Jul 08, 2016 at 04:12:14PM -0700, Guenter Roeck wrote: > > > On 07/08/2016 03:35 PM, Jiri Kosina wrote: > > > >Yeah, this topic again. It'd be a sad year on ksummit-discuss@ without it, > > > >wouldn't it? :) > > > > > > > >As a SUSE Enterprise Linux kernel maintainer, stable kernel is one of the > > > >crucial elements I rely on (and I also try to make sure that SUSE > > > >contributes back as much as possible). > > > > > > > >Hence any planned changes in the workflow / releases are rather essential > > > >for me, and I'd like to participate, should any such discussion take > > > >place. > > > > > > > > > > Same here. New employer, lots of unhappiness with stable releases, to the point > > > where stable trees are not used as basis for shipping releases. > > > That kind of defeats the purpose. So, instead of "let's ignore stable", > > > maybe we can get to a point where people feel comfortable with the quality > > > of stable releases, and where stable can actually be used as basis for production > > > releases. > > > > I wonder if it would not be a good idea to split stable into several > > flavors: security, fixes to core (really fixes), and fixes to device > > drivers + new hardware support. > > That would be sort of confusing IMO. > > The "one stable series per release" model is good, because it is really > straightforward and it is rather hard to get things wrong within it. It really depends on what you intend to do with it. For general-purpose distribution - yes, you take everything and cross your fingers that we fixed more bugs than introduced new ones. When you building kernel for set of devices you might want to be more selective because you do know the subset of features and hardware you are using. > > > I feel that with current single stable > > tree (per stable release) we are too liberal with what we direct towards > > stable, with many changes not being strictly necessary, but rather "nice > > to have". > > To me, as long as they all are fixes, that's fine. It depends how much testing was done with them. Given that nobody has all hardware permutations that are in the wild and on severity of the bug sometimes it makes sense to skip stable and let it be till next release. > > I tend to think that all known bugs should be fixed, at least because once > they have been fixed, no one needs to remember about them any more. :-) > > Moreover, minor fixes don't really introduce regressions that often Famous last words :) > (from my > experience), because they tend to be simple. Significant fixes, on the other > hand, tend to be more complicated or more subtle and the risk of regressions > from them is so much greater. > Thanks. -- Dmitry