[Ksummit-discuss] [CORE TOPIC] stable workflow

[Takashi Iwai]

On Sat, 09 Jul 2016 02:10:46 +0200,
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. 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".

Well, I'm not sure whether splitting to these two categories would
improve the regression rate.  In general, a patch for a new hardware
is just adding something (like ID entries), and even if it's buggy, it
shouldn't affect other older devices.  Of course, there are
exceptions, but judging from only my own experience, it's likely a
really small fraction.


thanks,

Takashi