RFC: Stable kernel updates and the SRU process

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

Ben Collins 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.
> I should point out that regardless of the upstream process, we have, in
> the past, gotten regressions due to these changes.
> Hence the reason we have the current policy.

Still I think it would be better to revert selectively if there are regressions
found than only to select a few patches and miss fixes until we get bitten by them.


When all other means of communication fail, try words!

More information about the kernel-team mailing list