MaverickPatchPolicy

Revision 5 as of 2010-05-05 18:48:13

Clear message

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

Before creating a patch it needs to be evaluated if another approach might not be better suited. For example most default changes in KDE can be carried out via kubuntu-default-settings. Please also note that additions to kubuntu-default-settings should generally be considered patches too, and discussed with upstream whether it is not appropriate to also apply the change in the upstream source code.

Should it indeed be necessary to carry out a code change it is important that some basic rules need to be kept in mind.

In general it should be tried to implement solutions that qualify for upstream inclusion, so that ultimately no patch is necessary at all, or only for the short amount of time between a Kubuntu release and a new upstream release.

Should it not be possible to do that either, then the following rules apply.

Patches adding more than 25 source lines of code, or more than 2 functions, or changing the interface of a function, must be reviewed and approved by upstream before inclusion into Kubuntu.

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

CategorySpec