RFC: Stable kernel updates and the SRU process

Tim Gardner tcanonical at tpi.com
Mon Oct 27 14:27:52 UTC 2008

Martin Pitt wrote:
> Hi Tim,
> Tim Gardner [2008-10-27  7:26 -0600]:
>> 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.
> Hm, I thought we already did backport fixes from -stable in SRUs, but
> I might misremember.
>> 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 agree, they are generally quite sane and also well tested.
>> I think we are remiss if we do not take advantage of that upstream
>> process to improve our kernel.
> I agree.
>> 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.
> They should still be subject to the process in terms of having them in
> -proposed, and document their testing in the associated bug reports.
> Due to the sheer number of SRU bugs, we cannot generally verify each
> and every fix anyway, but have resorted to keeping it in -proposed for
> quite a while, verifying only the bugs we can actually test on our
> systems or which we get feedback from users from, and looking out for
> regression reports.

I agree that _all_ kernels should be subject to the -proposed period of
testing, but I would like to avoid the duplication of effort that has
already gone into the stable kernel updates. For example, there are 43
functional commits in the 2.6.27.y tree that have not been applied to
Intrepid. Do _you_ want to write the SRU report for each of those
commits?  I sure don't.

> So unless a kernel patch has to go into -updates really quickly, I am
> all for including changes from upstream stable, provided that you read
> over them and check that they don't blatantly conflict with something
> we want to do in Ubuntu, and are otherwise ok.
> In a case where an upstream stable update would be the only part of a
> SRU, it should have an LP # which is listing the changelog and
> documenting testing feedback.
> Martin

Tim Gardner tim.gardner at canonical.com

More information about the kernel-team mailing list