[Ksummit-2012-discuss] [ATTEND] depth of our git tree structure; HID subsystem; kernel bugzilla; stable review

Guenter Roeck linux at roeck-us.net
Fri Jun 15 23:48:15 UTC 2012

On Fri, Jun 15, 2012 at 03:59:59PM -0700, Greg KH wrote:
> On Fri, Jun 15, 2012 at 03:32:13PM -0700, Guenter Roeck wrote:
> > My problems in respect to -stable are:
> > 
> > - stable tree submission process, which doesn't apply to all subsystems.
> >   Would be great to have a single well defined process for all -stable
> >   submissions.
> Have you read Documentation/stable_kernel_rules.txt?  Does that not
> describe the process properly?  What is it lacking?
Yes, I did read it. It doesn't apply to all subsystems, though (see below).

> >   That doesn't mean that all patches sent to -stable have to be
> >   handled by the same person, but the "patches for the XXX subsystem are not
> >   handled here" feedback is a bit odd for newcomers.
> I don't understand, no one should ever send a "new" patch to the stable
> list, is that what you mean?  It's pretty rare that it happens (once
> every few weeks), so I don't think people are getting all that confused.
I don't mean new patches. Sorry if I created that impression.

Patches for the net subsystem are not accepted on the stable list, and last time
I checked that was not documented anywhere, and is up to each individual to find
out. If it is documented now, my apologies for the noise.

> > - stable release selection process. Would be great to have some predictable
> >   process, ie to know ahead of time if a release is going to be a stable release.
> All releases are "stable" :)
> >   That would make long term release planning much easier.
> Ah, you mean the long-term releases, that's different.  I thought my


> discussion of this last year as to how I was going to pick this, cleared
> this up?  What do I need to do differently in this area?
> Oh, and if you couldn't figure it out based on my statements last year
> about 3.0 being a longterm kernel, that means that 3.4 will be the next
> longterm kernel I maintain.  Kernels outside of this "normal" longterm
> selection process are picked by others based on when they want to, and
> that is totally arbitrary, and can not be planned, nor do I think you
> want it to be.
I must have missed the announcement about 3.4 being the next longterm maintained
kernel by you, and, no, I wasn't able to deduct it from earlier statements.


More information about the Ksummit-2012-discuss mailing list