KernelKarmicReviewOfNonUpstreamedCode

Differences between revisions 1 and 2
⇤ ← Revision 1 as of 2009-05-13 12:03:34 →
Size: 2610
Editor: nc-65-40-95-196
Comment:
← Revision 2 as of 2009-05-16 09:32:00 → ⇥
Size: 2992
Editor: p5B2E6768
Comment:
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
 * '''Created''':  * '''Created''': 2009-05-16
Line 7: Line 7:
 * '''Packages affected''':  * '''Packages affected''': linux
Line 11: Line 11:
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. Code that was not upstream but useful to Ubuntu users has been carried in the ubuntu modules. However, now that staging exists, we should make every effort to remove code from there.
Line 15: Line 15:
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.		 (Only if there really will be drivers removed)
Some drivers have been removed as they where no longer maintained upstream.
Line 21: Line 20:
This should cover the _why_: why is this change being proposed, what justifies it, where we see this justified. All drivers in the ubuntu directory are not automatically synced with the kernel. This causes breakage and requires the ubuntu kernel team to either sync manually with a more recent version or modify that code to work again.
Code there will also be much less reviewed and worked on compared to the rest of the kernel.
Since the linux kernel now carries a staging tree which carries non-mature code in order to get it better tested and/or worked on, we should try to get all of our drivers in ubuntu moved over to staging.
Line 25: Line 26:
== Assumptions ==

== Design ==

You can have subsections that better describe specific parts of the issue.		  * Albert uses iscsitarget on Hardy. After upgrading to Intrepid it was broken as it was synced to some version that missed important fixes.
 * Bob used the prism2_usb module in Intrepid. It was usually not touched much often. Now the module is in the staging tree and get automatically maintained from upsream.
Line 33: Line 31:
This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like: We would have to assess and decide what to do with the following drivers currently in the karmic ubuntu directory:
Line 35: Line 33:
=== UI Changes ===  * aufs
 * compcache
 * dm-loop
 * dm-raid4-5
 * drbd
 * gfs
 * iscsitarget
 * lenovo-sl-laptop (ACPI driver for Lenovo SL laptops)
 * appleir (Apple USB infrared receiver)
 * fsam7400 (rfkill for Fujitsu Siemens Amilo M 7400)
 * lmpcm_usb (Logitech MediaPlay cordless mouse driver)
 * snd-bt-sco (Bluetooth SCI sound driver)
 * thinkpad_ec (access driver for the Thinkpad EC)
 * tp_smapi (enhanced battery control for Thinkpads)
 * ndiswrapper
 * av5100 (rfkill for Averatec 5100P)
 * pbe5 (rfkill for Packard Bell EasyNote E5)
Line 37: Line 51:
Should cover changes required to the UI, or specific UI that is required to implement this Some might get intentionally dropped as they are replaced by other drivers in the Karmic cycle. For the others we need to check whether they
Line 39: Line 53:
=== 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.		  * are actively maintained someplace
 * they are valid to be placed into the staging tree
Line 52: Line 58:
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.		 If drivers are only moved from ubuntu to staging, we only need to verify they are still build and included in the package. Replaced drivers need a specific plan, depending on the driver.
Line 58: Line 62:
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.  * If a driver is maintained somewhere else and the maintainer(s) do not want to see the driver included upstream, would DMKS be a plan B?

Summary

Code that was not upstream but useful to Ubuntu users has been carried in the ubuntu modules. However, now that staging exists, we should make every effort to remove code from there.

Release Note

(Only if there really will be drivers removed) Some drivers have been removed as they where no longer maintained upstream.

Rationale

All drivers in the ubuntu directory are not automatically synced with the kernel. This causes breakage and requires the ubuntu kernel team to either sync manually with a more recent version or modify that code to work again. Code there will also be much less reviewed and worked on compared to the rest of the kernel. Since the linux kernel now carries a staging tree which carries non-mature code in order to get it better tested and/or worked on, we should try to get all of our drivers in ubuntu moved over to staging.

User stories

  • Albert uses iscsitarget on Hardy. After upgrading to Intrepid it was broken as it was synced to some version that missed important fixes.
  • Bob used the prism2_usb module in Intrepid. It was usually not touched much often. Now the module is in the staging tree and get automatically maintained from upsream.

Implementation

We would have to assess and decide what to do with the following drivers currently in the karmic ubuntu directory:

  • aufs
  • compcache
  • dm-loop
  • dm-raid4-5
  • drbd
  • gfs
  • iscsitarget
  • lenovo-sl-laptop (ACPI driver for Lenovo SL laptops)
  • appleir (Apple USB infrared receiver)
  • fsam7400 (rfkill for Fujitsu Siemens Amilo M 7400)

  • lmpcm_usb (Logitech MediaPlay cordless mouse driver)

  • snd-bt-sco (Bluetooth SCI sound driver)
  • thinkpad_ec (access driver for the Thinkpad EC)
  • tp_smapi (enhanced battery control for Thinkpads)
  • ndiswrapper
  • av5100 (rfkill for Averatec 5100P)

  • pbe5 (rfkill for Packard Bell EasyNote E5)

Some might get intentionally dropped as they are replaced by other drivers in the Karmic cycle. For the others we need to check whether they

  • are actively maintained someplace
  • they are valid to be placed into the staging tree

Test/Demo Plan

If drivers are only moved from ubuntu to staging, we only need to verify they are still build and included in the package. Replaced drivers need a specific plan, depending on the driver.

Unresolved issues

  • If a driver is maintained somewhere else and the maintainer(s) do not want to see the driver included upstream, would DMKS be a plan B?

BoF agenda and discussion

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.

CategorySpec

specs/KernelKarmicReviewOfNonUpstreamedCode (last edited 2009-09-30 12:26:11 by p5B2E4121)