RFC: Stable kernel updates and the SRU process

Stefan Bader stefan.bader at canonical.com
Tue Oct 28 16:40:44 UTC 2008


Tim Gardner wrote:
> Stefan Bader wrote:
>> Tim Gardner wrote:
>>> I would like to propose the following change in policy with regard to
>>> the Ubuntu kernel and stable tree updates.
>>>
>>> In the past our kernels have incorporated stable kernel tree updates up
>>> to the point of kernel freeze. After that point, only those patches that
>>> were specifically referenced by SRU Launchpad reports were applied.
>>>
>>> The upstream process for stable tree updates is quite similar in scope
>>> to the SRU process, e.g., each patch has to demonstrably fix a bug, and
>>> each patch is vetted by upstream by originating either directly from
>>> Linus' tree or in a minimally backported form of that patch.
>>>
>>> I think we are remiss if we do not take advantage of that upstream
>>> process to improve our kernel. Therefore I propose that we modify our
>>> kernel update policy such that we adopt stable kernel updates at
>>> appropriate points in the release process (avoiding kernel freezes etc)
>>> for as long as upstream continues to provide updates, and that these
>>> stable kernel updates not be subject to the SRU process.
>>>
>>> Comments?
>>>
>>> rtg
>> I would also be in favor of such a change. In the past there have been several
>> bug that were fixed by changes in the stable tree which we had to search for
>> and then pull in. Also the patches in the stable tree are generally small and
>> it takes a review process to get them in. So why not simplify our workload by
>> pulling them in by default. I'd also only do one tracking bug per stable release.
>>
>> Stefan
>>
> 
> Stefan - I think there are still some 2.6.24.y patches that haven't been
> applied to Hardy.
> 

I think there are still quite a few of them. My list might be a bit outdated by
 now but there could be around 130 of them still not being applied. If we
change our policy, they should definitely go in.


-- 

When all other means of communication fail, try words!






More information about the kernel-team mailing list