KernelLucidSruPolicyReview
|
⇤ ← Revision 1 as of 2009-11-09 12:19:33
Size: 2594
Comment:
|
Size: 2979
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 4: | Line 4: |
| * '''Created''': * '''Contributors''': * '''Packages affected''': |
* '''Created''': 2009-11-11 * '''Contributors''': Stefan Bader * '''Packages affected''': All kernel related packages |
| Line 10: | Line 10: |
| This should provide an overview of the issue/functionality/change proposed here. Focus here on what will actually be DONE, summarising that so that other people don't have to read the whole spec. See also CategorySpec for examples. == Release Note == This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the release notes of the first release in which it is implemented. (Not all of these will actually be included in the release notes, at the release manager's discretion; but writing them is a useful exercise.) It is mandatory. |
For the Lucid development cycle we want to review our policy for accepting updates to the Karmic kernel. This is even more important as Lucid will be the next LTS and we want to spend as much focus and time on the Lucid development as we can. |
| Line 20: | Line 14: |
| This should cover the _why_: why is this change being proposed, what justifies it, where we see this justified. | With the upcoming LTS in mind we want to look at our SRU policy and adopt it to give users the fixes to bug (without causing regression) and at the same time minimize the effort spent on working in Karmic kernel code. |
| Line 22: | Line 16: |
| == User stories == | == Proposed Policy == |
| Line 24: | Line 18: |
| == Assumptions == | Any stable release update must come in form of a patch which has a Launchpad bug report associated. All patches are subject to review on the kernel-team mailing list and require at least two ACKs by senior members of the kernel-team. New kernel packages will be uploaded to a staging PPA first, then to proposed and after a retention period of at least 7 days with no regressions observed they will get moved to updates. |
| Line 26: | Line 21: |
| == Design == | Additionally to the generic requirements acceptable bugs fall into one of the following criteria: |
| Line 28: | Line 23: |
| You can have subsections that better describe specific parts of the issue. == Implementation == This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like: === UI Changes === Should cover changes required to the UI, or specific UI that is required to implement this === Code Changes === Code changes should include an overview of what needs to change, and in some cases even the specific details. === Migration === Include: * data migration, if any * redirects from old URLs to new ones, if any * how users will be pointed to the new way of doing things, if necessary. == Test/Demo Plan == It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage. This need not be added or completed until the specification is nearing beta. |
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 as long as the next release has not reached beta status. 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 3 months after a non-LTS release or the lifetime of a LTS release 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). Uploads containing a upstream stable patchset increase the retention period to two weeks. 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. |
| Line 57: | Line 31: |
| This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved. | * Need to setup a proper staging PPA. At the moment a team-members PPA is used, which is not optimal. * Make sure the staging area gets good test coverage. Kernel-team members should be required to run their machines with that included. * Discuss with SRU team about the proposed policy. |
| Line 61: | Line 37: |
| Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected. | Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarizing what was discussed and note any options that were rejected. |
Launchpad Entry: kernel-lucid-sru-policy-review
Created: 2009-11-11
Contributors: Stefan Bader
Packages affected: All kernel related packages
Summary
For the Lucid development cycle we want to review our policy for accepting updates to the Karmic kernel. This is even more important as Lucid will be the next LTS and we want to spend as much focus and time on the Lucid development as we can.
Rationale
With the upcoming LTS in mind we want to look at our SRU policy and adopt it to give users the fixes to bug (without causing regression) and at the same time minimize the effort spent on working in Karmic kernel code.
Proposed Policy
Any stable release update must come in form of a patch which has a Launchpad bug report associated. All patches are subject to review on the kernel-team mailing list and require at least two ACKs by senior members of the kernel-team. New kernel packages will be uploaded to a staging PPA first, then to proposed and after a retention period of at least 7 days with no regressions observed they will get moved to updates.
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 as long as the next release has not reached beta status. 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 3 months after a non-LTS release or the lifetime of a LTS release 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). Uploads containing a upstream stable patchset increase the retention period to two weeks.
- 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.
Unresolved issues
- Need to setup a proper staging PPA. At the moment a team-members PPA is used, which is not optimal.
- Make sure the staging area gets good test coverage. Kernel-team members should be required to run their machines with that included.
- Discuss with SRU team about the proposed policy.
BoF agenda and discussion
Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarizing what was discussed and note any options that were rejected.
specs/KernelLucidSruPolicyReview (last edited 2009-12-01 18:51:06 by 79-66-190-151)