Ubuntu Wiki

• Launchpad Entry: hardware-kernel-n-stable-frankenkernel-maintenance

• Created: 2010-10-05

• Contributors:

• Packages affected:

Summary

Check which drivers in released kernels are non-standard for the basic release and decide how to handle stable maintenance on those.

Release Note

This should not have any impact on the release notes.

Rationale

Starting at least with Lucid we had various drivers being replaced by versions from newer kernels before release. This can, in some cases lead to those miss some upstream stable updates as the changes may not apply to the drivers in the kernel base but could be necessary for the newer driver. How can we handle that best?

Assumptions

• The deviations are documented in a KernelDriverDeviations

Design

In the range of deviated drivers, the DRM subsystem in Lucid is an even more special case. While the main kernel is a LTS release, the DRM parts have been taken from 2.6.33. And while 2.6.32 is also a long term supported kernel upstream, 2.6.33 has already been discontinued. However, graphics being one of the most noticeable systems, it was clear that we need something there. So we maintain a stable combined tree on kernel.org which follows Greg's 2.6.32.y stable tree but adds patches for DRM. Currently we get submissions from Debian and from our various teams only. And the process to queue things up is not very visible.

Currently submissions are taken from the kernel-team mailing list and are then added at some point. Also scanning patches applied to 2.6.32.y and the most recent upstream stable tree. But there should be some feedback when queuing things.

• Send out mails to all SOB/CC about queuing the patch?
• Send out announcement mails to LKML whenever a new DRM33 release was uploaded?

For other more recent drivers:

• Should be actively scan for stable updates after the kernel they came from is no longer supported upstream?
• Should drivers taken from a rc tree be always SRUed to the upstream release version?
• Is there a way to trigger at least some warning when applying patches to deviated drivers?

Implementation

This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:

Unresolved issues

This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.

BoF agenda and discussion

Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.

CategorySpec