[Ksummit-2012-discuss] [ATTEND] stable kernel stuff and grumpy maintainers

Jiri Kosina jkosina at suse.cz
Mon Jun 18 18:42:32 UTC 2012

On Mon, 18 Jun 2012, Andrew Morton wrote:

> > > > I'd like to discuss:
> > > >   - The stable and longterm kernel release process, is it going well for
> > > >     everyone?  Are there things we can do differently?  How can I kick
> > > >     maintainers who don't mark patches for stable backports in ways that
> > > >     do not harm them too much?  How can I convey decisions about the
> > > >     longterm kernel selection process in a better way so that it isn't
> > > >     surprising to people?
> I think it's a good topic.  It's a pretty important one, isn't it? 
> This is the tree which most everyone in the real world bases kernels
> on?
> It would be useful to get input from -stable's "customers".  Mainly
> distros I guess.  

Fully agree, and I have actually already suggested that in my pile of 
topic proposals.

One issue we are having with stable tree merges into our enterprise kernel 
is that the releases don't always match our release timing and policies we 

A particular real-life example: we are between last two release candidates 
of the enterprise distro release. For a good reason we are, at this stage, 
allowing *stricly* only high-priority bugfixes (user triggerable crashes, 
data corruptions, security issues).
This is not really in line with a huge pile of patches that come with each 
and every -stable release. And, frankly, -stable releases don't really 
include solely the patches listed above as high-priority; so we end up 
cherry-picking from -stable before releasing anyway.

This is not really a day-to-day scenario, but happens time to time.

I don't really think there is a way how we could solve this for -stable. 
The only way would be "limit all the -stable patches to solely data 
corruption, crash, or security issue fixes", but I am not sure how 
practical that would be.

Jiri Kosina

More information about the Ksummit-2012-discuss mailing list