[Ksummit-2012-discuss] [ATTEND] stable kernel stuff and grumpy maintainers
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
> 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
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.
More information about the Ksummit-2012-discuss