RFC: Stable kernel updates and the SRU process (conclusion)

[Tim Gardner]

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

After some discussion it has been decided that stable upstream updates
will be applied with the caveat that each patch is scrutinized for
possible regressions.

Only one Launchpad report will be created for each stable update series,
though I suspect regressions will warrant separate bug reports.

The one concept that I failed to mention in the original RFC is that of
forcing an ABI bump for these updates. None of the patches in
v2.6.27.3-v2.6.27.4 require an ABI bump. However, in the event that one
of these patches _does_ cause a regression, I think it is important to
be able to fall back to a previously installed kernel.

Does anyone have constructive comments regarding ABI bumps? I'm well
aware of the issues regarding third party partner kernel modules. IMHO
these kernels will spend enough time in -proposed [1] that partners will
have time to update their modules prior to release in -updates. Or
better yet, they'll have time to implement an ABI agnostic packaging
mechanism such as DKMS.

[1] The idea has been put forth that kernels be moved into -updates at
fixed times, perhaps on a quarterly basis, a change from the current
policy of 7 days testing in -proposed. Of course, there will have to be
a freeze period before being released.

rtg
-- 
Tim Gardner tim.gardner at canonical.com