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

[Steve Langasek]

On Wed, Nov 05, 2008 at 08:52:59AM -0700, Tim Gardner 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.

> 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.

Given the stated upstream policy for accepting patches I think I'm
comfortable with this, with the proviso that if a bug fixed in the kernel
stable tree update already has a bug report in LP, that bug report should be
referenced in the SRU changelog (as with existing practice) and the standard
SRU verification should apply to that bug in particular so that we can be
assured that it's fixed when pushing the update.

If a given patch is determined to be a source of possible regressions, this
should be documented in the SRU bug according to the current policy, and
should also be tested for explicitly prior to pushing the update.

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

Confirmed regressions should be blockers for publishing a kernel SRU, as
they are for other SRUs; if they happen to be reported as separate bugs, the
bug reports need to be linked to the SRU bug report so we know not to
push the SRU.

> 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.

I share Martin's concern here.  I wouldn't like to see the ABI field
repurposed; the field exists to ensure consistent package dependencies and
module paths, and bumping it every time there's a kernel SRU is just going
to mean extra, gratuitous rebuilds (either in the archive for packages like
lbm, or on end-user systems for modules using DKMS).  Publishing ABI-bumping
kernel SRUs is unpleasant enough on the archive side that I wouldn't like us
to do more of these than strictly necessary.

I think last-good-boot, plus very rigorous regression testing prior to
publishing in -updates, is the better solution.  Letting regressions reach
-updates should be avoided at all costs, regardless of what the rollback
path looks like; I don't think the kernel should be special in this sense.

Cheers,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org