[Ksummit-2012-discuss] [ATTEND] depth of our git tree structure; HID subsystem; kernel bugzilla; stable review
greg at kroah.com
Fri Jun 15 22:59:59 UTC 2012
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
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.
More information about the Ksummit-2012-discuss