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

[Greg KH]

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?

>   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.

> - 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.

thanks,

greg k-h