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