JauntyKernelTeamProcess

Revision 5 as of 2008-11-27 00:23:06

Clear message

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

Kernel Re-base

SAUCE Patch Triage

  • This is a notification point

Firmware Load Triage

  • This is a notification point

Configuration (re)Definition

  • This is a notification point

Development

Freeze Milestones

Update Process

SRU Release Points

Retirement

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

  • Identify components
  • Decision criteria for inclusion/removal, i.e. ubuntu patch superceded by upstream
  • Licensing. Defined review process including legal.
  • Stakeholders. Who is interested? Who will be inconvenienced/incensed?

Notification Process

  • Who gets notified?
  • Communications path: email, release notes, wiki page
  • When? How often?

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:

  • Early in the cycle is better than later. What are the bounds?
  • A decision to re-base depends on the value of new upstream work.
  • The impact on the rest of the distribution must be known. Possible regressions in user-land packages should be identified and documented.

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.

Ubuntu Patch Management

It is very unlikely that the Ubuntu kernel will be identical with the upstream. The following issues apply:

  • Some upstream features, such as the RT patches, are not in the mainline yet.
  • There are Ubuntu specific configurations and code that are necessary for the distribution but will not meet the upstream requirements for mainline inclusion.
  • Some upstream features/options will be disabled in Ubuntu kernels.
  • The kernel package release notes should describe the additions/deletions and document the reasons for each.

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.

  • The packaging process should be as automatic as possible from the git pull to the push to the PPA archive.

  • There must be a process in place to decide when to generate a package. For example, daily packaging of potentially unstable or unbuildable kernel trees is wasteful and packaging very late in the release cycle limits testing availability.
  • The package list and kernel configuration variations may not be as extensive as for the supported kernels.

Unresolved issues

BoF agenda and discussion

pgraner's notes

  • Tree Mgt & Process & Kernel Packaging

    • New release tasks
      • Patch review
        • Need to be sure that when we drop a patch, it's an explicit decision, and coordinated with developers who might be depending on it.
        • next rebase to include a public review of all patches and their fate (e.g. on ubuntu-devel@lists)?
        • Upstreaming of Sauce patches.
    • Kernel Subsystem updates

      • Matching of Kernel -> Userspace components

  • Notification?
    • Review
      • Firmware review
        • What can be deprecated, removed and whats new? License OK.
        • License review procedures.
        • Who is involved? Tech Board? Legal? sabdfl?
  • Kernel Version
    • Checkpoints thought the cycle to ensure we don't hit the 2.6.27 late cycle issue
  • New kernel features
    • Diffing of config
    • What constitutes us turning on a feature?
    • Approval
    • HWDb
    • New 3rd party code/firmware.
    • License review
    • Tracking files
  • ABI (yet one more time)
    • List of symbols that vendors need?
      • VMWare
      • Parallels
      • Others?
  • SRU Release Points
    • Predictable release of SRUs (time baesed)
    • Security as needed
    • Try and schedule ABI security bumpers and bugs at same time
  • Upstream Vanilla Kernel Package
    • Is ths something we can start providing?
    • Beneficial for bug reporters to test the upstream kernel
    • Will also improve the upstream bug reporting process

References

CategorySpec