Ubuntu Wiki

• Launchpad Entry: kubuntu-maverick-patch-policy

• Created: 2010-05-05 by HaraldSitter

• Contributors: HaraldSitter

• Packages affected: All belonging to the Kubuntu package set.

Summary

As presented in the Kubuntu/Specs/LucidPackaging, it is necessary and asked of the Kubuntu developers to keep the amount of patches as low as possible and ensure the highest possible quality of those that are necessary. This specification is targeting to formalize the rules regarding patching in order to archive aforementioned objectives.

Release Note

TODO

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.

Rationale

Over time more and more patches get added to packages, be it to fix bugs introduced by upstream, or to make the software fit better into the Kubuntu system. Each patch however requires a certain amount of maintenance, so it is desired to keep the amount of patches as low as possible, in order to keep developer resources free for more important things than maintaining patches. Additionally each patch comes with the risk of introducing an issue that would not have appeared with the canonical upstream source, once again increasing the maintenance efforts of such a patch.

It became apparent that patches expose the following issues:

• Deriving from canonical upstream source means that upstream can not give their best support, increasing the amount of support and bug tracking/management/fixing in Kubuntu.
• Deriving from canonical upstream source bares a mostly great risk of introducing bugs, since the patch author will most likely not be an upstream author, hence might not fully be aware of their change's implications.
• Deriving from canonical upstream source will make upstream grumpy with Kubuntu, since some users will always report issues to the upstream authors, even if they are not responsible, nor knew anything about the code causing the issues.
• Deriving from canonical upstream source means that a delta gets added that needs to be maintained by the Kubuntu developers.
• Introducing a delta to the upstream source base almost certainly inflicts that someone who did not create the patch, nor knows nothing about the upstream source, will have to struggle with updating the delta in case upstream changed the affected source portions around.

This policy is expected to reduce the application of patches in Kubuntu, to reduce the exposure to above listed issues.

Developer stories

• Kevin is a KDE developer and bug triager. Every once in a while, Thomas strives through the KDE bug tracking system, triaging bugs. He is very happy that, unlike other distributions, Kubuntu does not seem to apply large amounts of buggy patches, and he does never hit a bug that was caused by Kubuntu.
• Fathi is a Debian developer and very happy that every once in a while he gets told about the latest and greatest Kubuntu patches, that might be interesting for Debian, so he can incorporate them in Debian and make Debian a better product.
• Scott is a Kubuntu developer and glad that he does not have to update 30 patches for each new KDE release.
• Jonathan is also a Kubuntu developer and likes that he can spend most of his time developing new cool stuff in stead of digging through endless amounts of bug reports that were caused by a patch some unknown developer wrote 5 years ago.

Assumptions

Design

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:

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.

Unresolved issues

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.

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