RFC: Stable kernel updates and the SRU process
tcanonical at tpi.com
Wed Oct 29 13:54:40 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.
>> I would also be in favor of such a change. In the past there have been
>> 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.
I think the odds of any particular stable update causing a regression
are no different then the average SRU patch because typically we won't
accept an SRU patch of any complexity unless it originates from
upstream, the source of all stable patches anyway.
Tim Gardner tim.gardner at canonical.com
More information about the kernel-team