KernelUpdates
Differences between revisions 8 and 26 (spanning 18 versions)
|
Size: 4117
Comment: Wiki gardening
|
Size: 4430
Comment: just add a link to kernel-team@lists.ubuntu.com
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 8: | Line 8: |
| There are several categories of updates, in addition to normal security updates: | In addition to the generic SRU requirements, we will accept patches which fall into any of the following categories: |
| Line 10: | Line 10: |
| * Critical bug fixes. These are categorized as non-security issues relating to bugs that affect a large range of users. These are bugs that keep users from reliably using their systems, or prevent booting at all. These patches must pass through rigorous testing by Canonical/Ubuntu and the community at large. * Supported vendor patches. These are patches generally related to hardware support. If they are very specific to a piece of hardware, the nature of the patch makes regression on other hardware unlikely or impossible, and we have the hardware available for thorough testing, then it can be part of an SRU. Otherwise they need to be maintained in a separate repository/pocket/PPA specific for that vendor or, if appropriate, in `linux-backports-modules`, and thus need to be maintained separately in the future. * Mainline Stable Updates. These are upstream blessed patches which are deemed important enough to backport to older releases. These patches must pass testing both upstream and by Canonica/Ubuntu. Other changes are generally avoided on stable kernels, since the regression potential is so exceptionally high. All non-security changes need to follow the standard SRU procedure in terms of having a bug associated with them, which is fixed in the development release and signed off by `ubuntu-sru` or `canonical-qa`, and the changelog needs to include the bug number. == How long will updates be allowed for a release == This answer is directed at non-LTS releases. For normal 18-month releases, we will only accept updates to the kernel for 3-4 months after release. At this point we consider the in-development release to be stable enough for testing, and the primary target for fixing bugs. Plus, 3-4 months after release, most major bugs are either reported and fixed in the stable release, or deemed unfixable. There may be a few exceptions to this, but don't count on them. |
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. 1. 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. 1. 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). 1. Fixes to drivers which are not upstream are accepted directly if they fall into the first two categories. |
| Line 25: | Line 16: |
| == Mainline Stable Updates == | == How does the process work? == |
| Line 27: | Line 18: |
| Where mainline is providing stable updates (the stable maintainer trees stable-2.6.27.y etc) these will be considered for inclusion as they release. | * 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 https://wiki.ubuntu.com/Kernel/Dev/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: {{{ SRU Justification: |
| Line 29: | Line 23: |
| For non-LTS releases these will generally be incorporated in full for the initial 3-4 month bug fixing period. After this patches will only be incorporated where there is demonstrated user need, following the normal SRU process for each change. | Impact: <a short description about the symptoms and the impact of the bug> Fix: <how was this fixed, where did the fix come from> Testcase: <how can the fix be tested> }}} * 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 the the [[mailto:kernel-team@lists.ubuntu.com|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:{{{ To: kernel-team@lists.ubuntu.com Subject: [<series>] SRU: <bug/patch title> |
| Line 31: | Line 32: |
| For LTS releases these will generally be incorporated in full for the life of the release. These will necessitate longer baking of the releases in -proposed to weed out possible regressions. It should be noted that as the release matures the flow of these updates are expected to slow significantly as the release diverges further from the development version. | <SRU justification copied from the bug> |
| Line 33: | Line 34: |
| == How will updates be provided in the archive == | <patch inlined or pull request> }}} * 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? == |
| Line 35: | Line 40: |
| * Urgent security updates will be uploaded directly into -security without other changes. This just requires a temporary GIT fork which will be immediately merged back into the main branch for that stable release. * Less urgent security updates and non-security patches will be uploaded to -proposed and then just follow the normal SRU QA procedure (testing, confirming bugs, etc). After verification, these kernels are copied verbatim to -security, and the USN is issued. This avoids maintaining two GIT trees for stable releases while still keeping the testing period. * Non-security updates which change the ABI should be either avoided at all, or be combined with security updates which require ABI change anyway. |
* Security updates will be uploaded directly into -security without other changes. This just requires a temporary GIT fork which will be immediately merged back into the main branch for that stable release. * Normal updates will be provided as pre-releases through the kernel-ppa users PPA. At certain points those get made into proposed releases which are uploaded to the proposed pocket. Then again they have to get verified to fix the problems and not to cause regressions. |
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:
- 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.
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.
- 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).
- 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 https://wiki.ubuntu.com/Kernel/Dev/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:
SRU Justification: Impact: <a short description about the symptoms and the impact of the bug> Fix: <how was this fixed, where did the fix come from> Testcase: <how can the fix be tested>- 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 the 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:
To: kernel-team@lists.ubuntu.com Subject: [<series>] SRU: <bug/patch title> <SRU justification copied from the bug> <patch inlined or pull request>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. This just requires a temporary GIT fork which will be immediately merged back into the main branch for that stable release.
- Normal updates will be provided as pre-releases through the kernel-ppa users PPA. At certain points those get made into proposed releases which are uploaded to the proposed pocket. Then again they have to get verified to fix the problems and not to cause regressions.
KernelTeam/KernelUpdates (last edited 2025-06-25 18:43:45 by ahasenack)