KernelUpdates
Differences between revisions 1 and 13 (spanning 12 versions)
|
Size: 1574
Comment: Initial entry
|
Size: 3940
Comment: Misc clean ups to reflect current kernel SRU policy
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| == Kernel Updates for Stable Releases == | ## page was renamed from KernelUpdates = Kernel security and update policy for post-release trees = |
| Line 3: | Line 4: |
| Procedures for on-going updates to stable releases of the kernel. | 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. |
| Line 5: | Line 6: |
| Patches to the kernel not related to security will first appear in <release>-proposed. To use these kernels, you must add a line to your ''/etc/apt/sources.list'' file: | == What sort of updates are allowed for post-release kernels? == |
| Line 7: | Line 8: |
| {{{ deb http://archive.ubuntu.com/ubuntu <release>-proposed main restricted |
Additionally to the generic requirements acceptable bugs fall into one of the following criteria: 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. 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. 1. ''$DEITY'' intervention. Might happen, but very very rarely and will not be explainable. == 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 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> |
| Line 10: | Line 27: |
| * If the fix for a problem meets the requirements for a SRU and has also been tested to successfully solve the bug, then the next step depends on whether the fix is serious enough to be directly applied an Ubuntu kernel series or whether it should go in via upstream stable (as long as that is appropriate). * For serious problem fixes, the patch must be sent the the kernel-team mailing list. There is requires ACKs from two senior kernel-team members and then will be applied to the Ubuntu kernel tree. Even though going into the tree on the faster path, the next step should also be done. {{{ To: kernel-team@lists.ubuntu.com Subject: [<series>] SRU: <bug/patch title> |
|
| Line 11: | Line 32: |
| Currently, there are no ''linux-meta'' packages, so updates will have to be manually installed initially. Use this command: | <SRU justification copied from the bug> |
| Line 13: | Line 34: |
| {{{ sudo apt-get install linux-image-2.6.15-50-<flavour> linux-restricted-modules-2.6.15-50-<flavour> |
<patch attached or pull request> |
| Line 16: | Line 36: |
| * For all other patches (as long as the upstream stable is appropriate) the fix has to be sent upstream (when the problem is there as well and the patch is not a backport) and to stable@kernel.org (if it has not been sent there before). As soon as that is accepted there, it will come back its way when we pull stable updates. == How will updates be provided in the archive == |
|
| Line 17: | Line 40: |
| Where ''flavour'' is one of 386, 686, k7 (for i386 dapper). If you have a different architecture, or are using some other stable release besides dapper, this may change a little. If you do not need linux-restricted-modules, you can choose not to install that. The ABI (50) will remain the same. Other releases will change the kernel version. For example, it will be 2.6.17 for edgy, instead of 2.6.15. Eventually, stable patches to this kernel will be migrated to the main stable release. Testing (by you) is required to make this happen. All changes from the stable kernel are listed in the top level changelog entry (there are not multiple entries in the changelog for each upload, just a single rolling entry). When changes are migrated to the stable kernel, they will be removed from the ''proposed'' changelog entry. Every effort will be made to keep the ''proposed'' kernel synced with security updates, but do not count on it. ---- CategoryKernel |
* 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?
Additionally to the generic requirements acceptable bugs fall into one of the following criteria:
- 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.
- 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.
$DEITY intervention. Might happen, but very very rarely and will not be explainable.
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 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 a SRU and has also been tested to successfully solve the bug, then the next step depends on whether the fix is serious enough to be directly applied an Ubuntu kernel series or whether it should go in via upstream stable (as long as that is appropriate).
For serious problem fixes, the patch must be sent the the kernel-team mailing list. There is requires ACKs from two senior kernel-team members and then will be applied to the Ubuntu kernel tree. Even though going into the tree on the faster path, the next step should also be done.
To: kernel-team@lists.ubuntu.com Subject: [<series>] SRU: <bug/patch title> <SRU justification copied from the bug> <patch attached or pull request>For all other patches (as long as the upstream stable is appropriate) the fix has to be sent upstream (when the problem is there as well and the patch is not a backport) and to stable@kernel.org (if it has not been sent there before). As soon as that is accepted there, it will come back its way when we pull stable updates.
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 2020-10-22 12:03:42 by anthonywong)