Summary

Review of the current kernel team processes for all stages of the release cycle.

Release Note

There are no end user impacts in this process definition work. The intent of this proposal is to improve internal processes.

Rationale

The Intrepid development cycle exposed a number of areas where the kernel team could improve the process. For example, regressions were introduced because patches or drivers were not carried foreward from the previous release. Processes, particularly decision processes, must be documented and published during the cycle. The kernel team and the work expected of it continues to expand and the current process is not scaling well.

Assumptions

The intent is to make no assumptions about "How Things are/were Done". Many new members of the team have little experience of the Debian/Ubuntu history.

Development Cycle

The development cycle starts with the opening of a new source tree and ends when support for the release expires.

Initial Planning

The initial planning has two goals. First, it defines and documents exactly what the kernel for this development cycle includes and, more importantly, what it drops. Each change will include a rationale for the change. Second, the result is published to all interested parties.

A key part of planning is to report the status of this work to the UDS where it will be reviewed.

The result of this work is not cast in stone. It will change as development proceeds but any changes in direction will also be published. The final version, including the rationale for each change will be published in the release documentation.

Kernel Re-base

The initial part of this work is more or less mechanical once the baseline kernel is chosen from the upstream. The final step is to isolate the differences between the current release tree and the mainline tree used for the re-base. These differences are Ubuntu specific changes that must be triaged.

SAUCE Patch Triage

Patches isolated during the re-base fit into the following categories:

This is a notification point that follows the process defined below. The documentation sent out in the notification shall document each change from the "vanilla" kernel, including a rationale for the change. Note that each change does not mean every changeset. The granularity of this is at the level of user visible subsystem or feature.

Firmware Load Triage

Firmware comes from an outside source, most often the hardware vendor. It has its own release and retirement schedule.

This is a notification point that follows the process defined below.

Configuration (re)Definition

The kernel configuration file .config controls what is included in the kernel. Since the kernel is what this file defines it to be, its contents must be controlled during the life of the release.

This is a notification point that follows the process defined below.

Development

Detail TBD

Freeze Milestones

There are alpha and beta releases. The process is TBD.

A new release will most likely cause a change to the ABI. Since this type of change affects 3rd party vendors, ABI changes in any of these releases will trigger a notification to the affected stakeholders. The notification will include the specifics of the change.

Update Process

Changes to final releases are restricted to bugfixes and security patches.

SRU Release Points

Retirement

Source tree and Launchpad bugs process TBD.

Review and Notification

At various stages of the development cycle, formal, documented reviews of certain items such as patches or firmware take place. The results of these reviews and the decisions made must then be communicated to the appropriate people and groups.

Review Steps

Notification Process

Kernel Specific Issues

Kernel Version Choice

The release cycle is long enough that it is possible that at least one, if not two kernel releases from upstream could occur within the development cycle. This brings up the following issues:

Feature Configuration Management

Kernel configuration for the various flavors of kernel are somewhat ad hoc and could use some structure.

Some embedded distributions have broken the kernel configuration file into generic, board/arch specific options, and "feature" options. They also have tools to merge and "layer" these configuration fragments into a final configuration for the build. This may be a useful model for re-factoring server/generic/desktop/notebook etc. configurations into something manageable.

Kernel Subsystem and User Land Dependencies

In the past, kernel features were added/enabled but there was no tracking of the user land part of the feature. The user land development fell behind, making the kernel component unusable. There should be a process in place to track the kernel and user land tasks. One option is to create open general release bugs in Launchpad with tasks to track both the kernel and user land work.

ABI Management

ABI changes can cause breakage in 3rd party packages. A process for identifying ABI changes and notifying impacted 3rd parties is defined.

Vanilla Kernel Packaging

The often requested Vanilla Kernel is an Ubuntu packaging of what is the current Linux release. This is not a supported kernel but it is useful for the isolation of reported bugs and the testing of upstream patches and features. Given the volatile nature of the Linux 2.6 HEAD, the packaging has to be controlled.

Unresolved issues

BoF agenda and discussion

References


CategorySpec

KernelTeam/Specs/JauntyKernelTeamProcess (last edited 2008-12-01 22:56:40 by lieb)