Updated new SRU policy spec

Tim Gardner tim.gardner at canonical.com
Fri Jun 12 16:02:52 UTC 2009


Luis R. Rodriguez wrote:
> On Tue, Jun 9, 2009 at 10:39 AM, Stefan Bader<stefan.bader at canonical.com> wrote:
>> I updated the spec about our new SRU policy on
>>
>> https://wiki.ubuntu.com/KernelTeam/Specs/SRUPolicyReveiw
>>
>> from my understanding of the outcome of the discussion. If this looks good I
>> would go forward and update out wiki page with that.
> 
> Few questions, some silly, some not that silly:
> 
> * What is SRU?
> 

Stable Release Updates - https://wiki.ubuntu.com/StableReleaseUpdates

> * What are "OMG kitten killer bugs" ? :)
> 

An expression I acquired from Matthew Garrett. Like pornography, you'll
know an OMG kitten killer bug when you see it. Is that definite enough?

> * Can a requirement be that patches must first have an equivalent
> upstream SHA1 sum on the stable kernel and mention that in the commit
> log entry? If the concerns is that the patches may take a while to
> trickle down the stable kernels then how about volunteering someone to
> join the stable kernel patch review cycle and help with that process?
> 

My intent is that updates to a released non-LTS kernel be throttled down
to a mere trickle, e.g., CVE and oops fixes only. I want the bulk of the
 distro kernel dev efforts directed at upstream where I believe we can
be more effective in the long run.

Any patches that are applied to a released kernel _must_ (with few
exceptions) originate from upstream, either Linus' tree or one of the
stable trees (which is effectively the same place).

> * If for whatever reason the above is not possible ensure that at
> least the patch has been posted and refer to URL for the patch in the
> commit log entry.
> 

All non-administrative commits to a released kernel _must_ have the
original upstream SHA1, e.g., 'git cherry-pick -x ...'

rtg
-- 
Tim Gardner tim.gardner at canonical.com




More information about the kernel-team mailing list