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

Jiri Kosina jkosina at suse.cz
Wed Jun 20 19:09:47 UTC 2012


On Wed, 20 Jun 2012, Greg KH wrote:

> > Agreed, and I am of course not asking anybody to decide for distros; just 
> > trying to make the decision process easier for them.
> > 
> > Even such a minimal categorization of bugs such as
> 
> First off, _who_ is going to do this categorization?  And how do you
> know it is correct?  Usually the original submitter doesn't know this,
> and often times, the maintainer doesn't either (sadly.)

Well, if neither maintainer, nor submitter, nor the original author of the 
patch knows what the actual impact of the patch is, I don't think it 
qualifies for stable :)

> > - support for new HW (so that we can drop those immediately, even 
> >   automatically, in certain development phases)
> > - performance improvement
> > - crash fix
> 
> Crashes seem like a security problem to me :)

There are scenarios in which this doesn't hold (crashes triggerable only 
by root, very artificial scenarios such as hardware evil on purpose, etc 
-- those can usually wait until a certain development stage is overcame; 
that is the decision that distros are to make).

> > - security fix
> 
> Good luck trying to figure out what is a "security fix" and what isn't.
> That plays into the whole problem that Linus and I are staying away
> from in trying to categorize things like this.

Yes, I know the discussion with Brad and other security people, and can 
actually understand both views.

> > - platform/hw-specific fix
> 
> Why isn't this a crash or security fix?

"Notebook XYZ reports 10 fahrenheits lower fan temperature without this 
patch" kind of things.

> Anyway, this is all nice, but really, is it that hard for distros to do
> this already on their own?  

Well, it shifts the initial categorization effort from someone who 
actually understands the code the most (developer/reviewer/maintainer) to 
the distro maintainers.
Yes, they have perform the final judgement anyway, but my whole point is 
trying to make this a little bit easier for them.

> They know their needs and where they are in their release cycle better 
> than anyone else, so they should be able to determine this.

Absolutely, stable shouldn't care about distro release cycles at all.

-- 
Jiri Kosina
SUSE Labs


More information about the Ksummit-2012-discuss mailing list