HWE Stacks for the 12.04.x

Registered by Leann Ogasawara

Given the current discussion of transitioning to a rolling release between LTS releases, how would we continue to deliver hardware enablement stacks for the 12.04.3 and 12.04.4 LTS point releases. We anticipate the point releases with enablement stack offerings will continue to play an important role in allowing Ubuntu to run on the latest hardware to hit the market. The purpose of this session is to discuss how we will continue to deliver hardware enablement stacks in subsequent point releases and how the HWE stack policies and procedures established today will be changed in the event that we move to a rolling release between LTS's.

Blueprint information

Status:
Started
Approver:
Leann Ogasawara
Priority:
High
Drafter:
Leann Ogasawara
Direction:
Approved
Assignee:
Canonical Kernel Distro Team
Definition:
Approved
Series goal:
Accepted for raring
Implementation:
Started
Milestone target:
milestone icon ubuntu-13.04-month-5
Started by
Leann Ogasawara

Related branches

Sprints

Whiteboard

== Session Summary ==

 1. Are we going to continue to develop a HWE stack for Precise in subsequent point releases ?
    1a. Maybe. There is discussion surrounding the need for a newer HWE stack for the 12.04.3 point release. ogasawara took a work item to sync with OEM project managers as well as the Server team if a new enablement stack is needed for 12.04.3. Some OEM representatives (eg superm1) noted they would skip the 12.04.3 release and use 12.04.4 for the next round of enablement. So maybe we only ship newer enablement stack for 12.04.4 and skip 12.04.3?

2. Can we put it officially in writing that we will continue delivering LTS point releases?
    2a. Yes. However, based on the outcome of 1a, we should be clear about what users will recieve from those point releases.

3. How will we choose the LTS HWE stack for the point releases moving forward if the interim releases no longer exist?
    3a. We will take into account release dates for point releases and cross reference that with the stability of the package(s) in the archive and also take into consideration hw vendor roadmaps. We will use all of this information to determine the most suitable package set which provides the necessary enablement for hardware hitting the market to be enabled in the point release.

4. How will we stabilize/test/bake the packages being delivered in the HWE stack for the point releases?
    5a. It was decided we would test and bake the packages for a period of time in the existing development release (eg let them bake in devel for ~3mo). At the same time we could also provide them in a PPA for testing in the LTS release. Once vetted in the development release, we would then introduce them into the -proposed pocket of the LTS release for further testing before providing them in the -updates pocket of the LTS.

5. How and when will we freeze the kernel for the point releases?
   5a. See 3a. We’ll freeze the kernel in time to satisfy the criteria in 3a.

6. How long do we support each HWE stack if Raring (and all interim releases from now on for that matter, transition to a rolling release model?
    6a. We will support them until the first point release of the next LTS. Eg, 12.04.2, 12.04.3, and 12.04.4 stacks would be supported until 14.04.1.

7. Do we only backport and support the versions of the HWE packages that go into the point releases? Or do we provide every new package version as an HWE stack?
    7a. Only support the versions of the HWE packages that appear in the point releases.

8. Current policy for the 12.04.x point releases states that consumers of the HWE stacks provided in the 12.04.2, 12.04.3, and 12.04.4 point releases will *NOT* automatically roll forward from HWE stack to HWE stack for each new point release until the next LTS. If we move to a rolling release model between LTS releases, do we want to re-evaluate this policy of automatically upgrading consumers of HWE stacks?
    8a. TBD. The topic was raised in the UDS session but no clear outcome was decided. The engineering teams see the benefits of the reduced cost in terms of maintenance if we automatically roll users forward. However, there is still a concern regarding stability. The concern over stability does not have any supporting evidence though at this time, but would still need to be addressed.

9. How should we name the meta packages since we won't have an official release name to leverage?
    9a. Until someone poses a better solution, we’ll use the the point release version string, eg 120403.

10. How will we handle the git kernel tree maintenance for the point releases. Topic branches? Separate repos?
    10a. The point releases live as 12.04.xx-master and 12.04.xx-master-next branches in the Precise kernel repo. In other words: “the point release will live as a branch within the original LTS repo”.

11. Where will we pull upstream stable patches from? Can we pull from normal upstream stable or will we have to again maintain our own extended stable?
    11a. The situation will remain the same as we have today. We will take advantage of upstream stable support when we can and provide our own when necessary.

12. How do we interlock the kernel and X for the point releases?
    12a. Communicate to the graphics team which kernel we’ll converge on for the point releases. Let both the kernel and X bake in the devel release before being introduced into the point release. See 3a.

13. Can the schedule for point releases be changed now to more closely match Intel's HW schedule rather than trying to retrofit and impose tight deadlines?
    13a. TBD. ogasawara took a work item to sync with OEM project managers as well as the Server team if a new enablement stack is needed for 12.04.3. Some OEM representatives (eg superm1) noted they would skip the 12.04.3 release and use 12.04.4 for the next round of enablement.

14. Are we going to update user-space utilities (e.g. btrfs-progs, etc) to match the updated kernels?
    14a. If there are required user space utilities which require updating in order to work with newer kernels delivered in the HWE stack, then yes they should be updated. For example, the kernel team interlocks with DKMS package maintainers to test their respective DKMS packages against the newer HWE stack kernels being delivered and to provide fixes if needed. I imagine the same coordination would/could take place with other user space package maintainers.

15. Would we ship a new enablement stack for 14.04.1?
    15a. TBD. We can address this if needed as 14.04.1 approaches.

(?)

Work Items

Work items for ubuntu-13.04-month-5:
[leannogasawara] sync with OEM project managers as well as the Server team and determine if a new enablement stack is needed for 12.04.3? Some OEM representatives (eg superm1) noted they would skip the 12.04.3 release and use 12.04.4 for the next round of enablement. So maybe we only need to ship a newer enablement stack for 12.04.4 and skip 12.04.3? (feedback supported HWE stack being needed for 12.04.3): DONE
[leannogasawara] Per the recent Tech Board decision to change the support duration for interim releases, document proposed changes for support and maintenance of future HWE stacks for LTS point releases (See https://wiki.ubuntu.com/Kernel/LTSEnablementStack#Proposed_12.04.3_.2B-_13.04_Hardware_Enablement_Stack_Policies_and_Procedures): DONE
[leannogasawara] Solicit feedback and agreement to proposed changes for support and maintenance of future HWE stacks for LTS point releases: DONE

Work items for ubuntu-13.05:
Raring HWE kernel uploaded to precise-proposed: DONE