## page was renamed from Kernel/Handbook/Developer <> ||<>|| 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|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|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|Kernel/Handbook/ReleaseManagement/KernelPackaging]] === Patch Review === <> === 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|Kernel/Handbook/ReleaseManagement/ReleaseMeeting]] === Adding Release Notes === <> 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|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 -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