The intention of this handbook is to outline the role of the Ubuntu Kernel Release Manager. For general developer information such as building a kernel, please refer to the the Kernel/Dev area of the wiki.
Role of the Ubuntu Kernel Release Manager
Every release cycle, a member of the Ubuntu kernel team is selected as the Ubuntu Kernel Release Manager. They are responsible for all aspects of the delivery of the Ubuntu kernel for that release. These responsibilities include, but are not limited to:
- Opening the release
- Maintaining the release
- Uploading the kernel package(s)
- Patch Review
- Weekly Release Meeting
- Adding Release Notes
- UDS Responsibilities
- Vendor Relationships
- Day 0 Kernel Upload
- Cleanup linux bugs nominated to release
Opening the Release
One of the first responsibilities for the Ubuntu Kernel Release Manager is to open and prepare the git tree for the upcoming release. The following wiki outlines the steps for starting this new git tree.
Kernel/Handbook/ReleaseManagement/OpeningRelease
Maintaining the release
An ongoing responsibility of the Ubuntu Kernel Release Manager is to maintain the master git repo and any subsequent branches and/or packages. The following wiki details the general process for maintaining the git repo's.
Kernel/Handbook/ReleaseManagement/MaintainingRelease
Uploading the Ubuntu kernel package(s)
In addition to maintaining the git repo's, the Ubuntu Kernel Release Manager is also responsible for building and uploading the linux kernel package(s). The following wiki describes this process.
Kernel/Handbook/ReleaseManagement/KernelPackaging
Patch Review
Patches are submitted to the Ubuntu kernels via the kernel-team mailing list. We use this list as the primary record of the discussions, acceptance, or rejection, of each patch (see Kernel/FAQ/GeneralMailingList). We use the patchworks patch tracking system to aid in this process http://patchwork.ozlabs.org/project/ubuntu-kernel/list/. See Kernel/Handbook/Patchworks for documentation on how we use patchworks within the team.
Weekly Release Meeting
At some point during the development cycle the Release Team will begin holding weekly IRC release meetings. This meeting takes place on FreeNode in #ubuntu-meeting every Friday at 1500UTC. The Ubuntu Kernel Release Manager is required to attend this meeting as a representative on behalf of the Ubuntu Kernel Team. Detailed information regarding the format of the meeting is outlined in the following wiki.
Kernel/Handbook/ReleaseManagement/ReleaseMeeting
Adding Release Notes
In some cases, a bug cannot be fixed for the release and will merit a release notes entry instead. To note this, use "Also affects project" to add a task on the ubuntu-release-notes project. Please make sure to explicitly nominate against a series, since release note can apply for multiple release. Please make sure the bug has a clear description, and if possible provide some sample text for the release notes. When the note has been added to the Release Notes, the status should be marked as "Fix Released"
For a full description of targeting release critical bugs, refer to https://wiki.ubuntu.com/RCBugTargetting
UDS Responsibilities
The Ubuntu Kernel Release Manager is responsible for the following items at UDS:
- Kernel Delta Review Blueprint/Spec
- Ubuntu Kernel Config Review Blueprint/Spec
- Ubuntu Kernel Version Blueprint/Spec
- Managing Blueprints/Specs for the entire Ubuntu Kernel Team
- UDS Kernel Track Scheduling
Detailed information for each of the above is documented at:
Kernel/Handbook/ReleaseManagement/UDS
Vendor Relationships
The Ubuntu Kernel Release Manager will also work with partner vendors to track any feature requests or enablement issues for the upcoming release.
Day 0 Kernel Upload
It's become a frequent occurrence that we will upload a Day 0 Kernel after an official release is announced. The Day 0 Kernel typically includes high priority bug fixes and security updates. The Day 0 Kernel is uploaded to -proposed and then pocket copied to -updates and -security if needed. It should be noted that we must always bump the ABI for the Day 0 Kernel regardless if it is required or not. This ensures that a user who installs from the CD has a known good fallback kernel in the event the Day 0 Kernel introduces any regressions.
Cleanup linux bugs nominated to release
At the end of each cycle, bugs which have been nominated to a release need to be cleaned up as follows:
If the bug won't be fixed in time for the release AND is not a candidate for an SRU - mark it "WON'T FIX"
If the bug won't be fixed in time for the release AND is a candidate for an SRU - milestone it as <release>-updates (eg. natty-updates), and leave the state alone.
If the bug won't be fixed in time for release AND is not a candidate for an SRU but is something that needs fixed in the next cycle - Add a nomination for the upcoming cycle (preserving the current status and importance) and mark the current release nomination as Won't Fix (eg. Natty task will have Won't Fix, Oneiric task will get status/importance of the Natty task).
- Only need to focus on the Critical/High bugs for the most part, but good to do a sweep over all
https://bugs.launchpad.net/ubuntu/natty/+source/linux/+bugs edit the release name in the url accordingly