KernelNattyStableFrankenkernelMaintenance

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

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.

Discussion

Review of the proposed STRAW MAN:

Types of patches:

1) stable upstream patches, are taken wholesale. No testing of individual functionality. 2) patch for a specific issue with a bug. Must have a tester with the hardware configuration who will test.

Patches will bake for a week, anything in (2) which is not verified will be dropped from the update. We will not attempt to verify stable updates. At the end of the week we upload the remainder. This is then tested before release to -updates.

For security we propose moving the non-critical/non-embargoed security patches to normal process. They will get rolled into the primary stable updates as the type (1) above.

For an embargoed patches we will push those out into the -security pocket as normal. Those patches come back as they do now, they are merged in and we re-upload -proposed. If this is in the first week then this should not rerestart the clock. In the second week if we cannot complete the regression testing then restart the second week.

What are certification/QA capable of testing in terms of volume. Where would certification/QA test be reported.

Security kernels need just as much verification and certification testing as all other kernels.

Actions

See the blueprints whiteboard for actions.

CategorySpec

KernelTeam/Specs/KernelNattyStableFrankenkernelMaintenance (last edited 2010-11-04 16:59:42 by 12)