diff --git a/docs/explanation/post-release-updates.md b/docs/explanation/post-release-updates.md new file mode 100644 index 0000000..27f47b6 --- /dev/null +++ b/docs/explanation/post-release-updates.md @@ -0,0 +1,89 @@ +# Kernel security and update policy for post-release trees + +This document describes the process and criteria for post-release kernel +updates. The kernel is a very complex source package, and it is fundamentally +different than other packages in the archive. The described process and criteria +are built on the normal [StableReleaseUpdates] document, and where these documents +conflict, this document takes precedence. + +## What sort of updates are allowed for post-release kernels? + +In addition to the generic SRU requirements, we will accept patches which fall +into any of the following categories: + +1. It fixes a critical issue (data-loss, OOPs, crashes) or is security related. + Security related issues might be covered by security releases which are + special in handling and publication. +2. Simple, obvious and short fixes or hardware enablement patches. If there is a + related upstream stable tree open (see below) this class of patches is + required to come through the upstream process. Patches sent upstream for that + reason must include their BugLink reference. +3. The patch is included in a corresponding upstream stable or extended stable + release. For the lifetime of both LTS and non-LTS releases we will be pulling + upstream stable updates from the corresponding series. There will be one + tracking bug report for each stable update but additional references to + existing bugs will be added to the contained patches (on best can do base). +4. Fixes to drivers which are not upstream are accepted directly if they fall + into the first two categories. + +## How does the process work? + +- First step for every SRU is to have a bug associated. +- The patch or patches must contain the link to the Launchpad bug and contain a + Signed-off-by line from the submitter. Please refer to [StablePatchFormat] for + detailed information regarding Ubuntu Kernel SRU patch formatting. +- The beginning of the description area of the bug needs to have a SRU + justification which should look like this example: + ```text + SRU Justification: + + Impact: + Fix: + Testcase: + ``` +- If the fix for a problem meets the requirements for SRU and has been tested to + successfully solve the bug, then the next step depends on whether the fix is + serious enough to be directly applied to an Ubuntu kernel series and/or + whether it should go in via upstream stable (as long as that is appropriate + for upstream stable). + - For fixes for serious issues, the patch should be sent to the + [kernel-team mailing list] in parallel to being submitted upstream. SRU + patches submitted for inclusion into an Ubuntu kernel require ACK's from at + least two senior Ubuntu kernel-team members before being applied to an + Ubuntu kernel tree. Again, even when going into an Ubuntu kernel tree on an + accelerated path, the patch should also be submitted upstream. Ubuntu Kernel + SRU patch submission format is loosely as follows: + ```text + To: kernel-team@lists.ubuntu.com + Subject: [] SRU: + + + + + ``` + - For all other patches which do not need an accelerated path into an Ubuntu + kernel, it is advised to push the fix upstream when appropriate, ie. the + problem exists upstream, and CC'ing [stable@kernel.org] during the process. + As soon as the patch is accepted upstream/upstream-stable, it will naturally + find it's way back down into our Ubuntu kernel when we pull + upstream/upstream-stable updates. This ensures patches are getting vetted + and applied upstream and reduces overall maintenance costs for the Ubuntu + Kernel Team. + +## How will updates be provided in the archive? + +- Security updates will be uploaded directly into -security without other + changes. The next full release will include these security changes in addition + to the normal changes. +- Normal updates will be provided as pre-releases through the corresponding kernel + build PPA. At certain points those get made into proposed releases which are + uploaded to the proposed pocket. Before proposed releases can migrate to other + pockets, it must be verified that the changes fix the targeted issues without + causing regressions. + +% LINKS + +[StableReleaseUpdates]: /explanation/stable-release-updates +[StablePatchFormat]: /reference/stable-patch-format +[kernel-team mailing list]: mailto:kernel-team@lists.ubuntu.com +[stable@kernel.org]: mailto:stable@kernel.org