All policies must be approved by the Kubuntu Council.
This policy outlines where bugs are tracked and what their primary states are.
Launchpad bugs have 5 primary states
Incoming bugs should get moved out of New as soon as possible to allow quick dealing with the issue.
Bugs that have been identified as not caused by KDE software should be moved to their respective packages for further triage.
Bugs in the packaging are always tracked on Launchpad. Bugs that prevent installation of a package (maintainer script erroring out, file conflicts between packages) should be resolved as soon as possible and therefore brought to the immediate attention of packagers; either through the mailing list or the IRC channel.
Bugs in Kubuntu specific software are, like packaging bugs, handled on Launchpad.
Upstream bugs are to be tracked in the upstream bug tracker http://bugs.kde.org. Upstream bugs reported on Launchpad are to be closed as Invalid with a comment asking the reporter to report the bug with KDE (also see Responses below).
Upstream bugs that were fixed upstream and reported with a request for backport are considered in the next section.
As an exception where upstream bugs are due to be tracked until the current release is out they can be filed, linked to upstream, tagged kubuntu and milestoned to the next release.
Users may file bugs that have an upstream fix available making the report either a SRU or backport bug. SRU bugs follow the Stable Updates policy from below, backport bugs (affects PPAs) are handled at the discretion of the respective triager and developer.
Please note that backport bugs must be reported against the kubuntu-ppa product rather than the relevant Ubuntu package.
In accordance with the Dead Upstream policy, unmaintained software may be kept in the archive when certain basic quality levels are met. Regardless though, all bugs except for one reference bug (see Dead Upstream Policy) are to be closed as Won't Fix.
To allow swift dealing with all common bugs, boilerplate bug comments are available at Kubuntu/BugTriage and may be used vigorously.
This policy outlines how to deal with software that is unmaintained upstream.
A new package of software that has a dead upstream must not be uploaded to the archive. No exceptions.
Existing packages of which upstream went AWOL have different approaches available, depending on the environment.
Unless otherwise requested by something upstream (see below), all unmaintained software should have their general viability assessed.
If any of the following questions can be answered with No, the software must be removed from the archive. Otherwise an individual developer may decide whether the package should be removed. Regardless, all bugs must be closed as Invalid with a comment about the unmaintained status. One bug report must be created and not closed (status: Triaged/High) explaining the unmaintainedness and why it is kept in the archive regardless.
KDE software is that accepted by KDE and compliant with the KDE Manifesto.
Before taking any actions regarding apparently unmaintained KDE software, KDE should be contacted for more information and opinion gathering (mail to kde-devel or kde-core-devel). If KDE manages to organize maintenance for the software it is to be considered collectively maintained by KDE; if not general viability rules apply. Unless KDE expresses explicit wishes with regards to whether the package should be kept in the archive, in which case those should be respected.
Software that is not accepted as part of KDE and not compliant with KDE's manifesto is considered unrelated to KDE.
Before taking any actions, at least one attempt should be made to assess whether upstream really is dead. The preferred way to do this is sending a mail to the biggest copyright holder or a respective mailing list. If no information is provided regarding the state of upstream within 14 days, the software is to be considered unmaintained and general viability rules apply.
To easily identify packages that have no upstream backing, a Dead Upstream Reference Bug must be filed against the package. This bug must not be closed until the package either becomes maintained again or is removed from the archive. The bug remains Triaged/High for the entire duration of its life time. Tags: "dead-upstream"
Subject: Dead Upstream Reference $NAME
An evaluation of the upstream maintenance and support of $NAME has yielded that unfortunately the upstream developer(s) have no more interest in moving the software forward. It was however decided by Kubuntu to keep the software available for installation as its quality is meeting our expectations and is still considered generally useful. All bugs reported against this package will be closed as Won't Fix as Kubuntu will not resolve any standing or new issues with the software.
Should you have any questions feel free to write a comment on this bug report.
For more information on the Dead Upstream Policy please check out the policy page at https://wiki.ubuntu.com/Kubuntu/Policies#Dead_Upstream
Software that is unmaintained but kept in the archive must not be patched! If the software breaks due to bit rot or similar things, it must be removed or whoever wishes to do the patching must take over upstream maintenance (not feature development).
Unmaintained software must not be distributed by default. Short term exceptions are allowed for software where a transition to a maintained replacement was not doable in the given time-frame of one release, as well as software that is maintained upstream but one of the required dependencies is unmaintained.
This policy outlines who can do what where when how why. Its primary purpose is to document people to poke for specific things.
High impact bugs are bugs that:
A bug is considered to have high impact if...
The Kubuntu Council has six members. Membership lasts for two years, staggered with three elected each year. Elections for the vacant positions are being held around May.
Council meetings have a quorum with a simple majority of members (four) present.
Kubuntu Members vote to select members of The Kubuntu Council.
Nominations should be asked for at least two weeks in advance of the vote. The vote should use the Condorcet Internet Voting Service and last two weeks.
Example election e-mails from previous years are: https://lists.ubuntu.com/archives/kubuntu-devel/2013-February/006805.html https://lists.ubuntu.com/archives/kubuntu-devel/2013-May/006956.html
The purpose of this policy is to clearly outline the requirements one has to fullfil to become a member of any of the Kubuntu Launchpad teams.
The only way to join the council team is being elected which will result in one of the present members adding you to the team. All members are also administrators of the team.
Kubuntu Developers are the people with upload rights to the official archive. This is limited to the packages inside the kubuntu package set. (ubuntu-archive-tools command> ./edit-acl -P kubuntu -S utopic query)
Kubuntu Members are the most trusted and devoted members of the community, having gained public recogition for their work on Kubuntu by being accepted as official Kubuntu Members. Membership in this team also makes you an Ubuntu Member.
Kubuntu Ninjas are the elite KDE software packagers. Ninjahood is considered a stepping stone for ascension to ~kubuntu-developer.
Used for git branches of our packaging
Team is locked down to ~kubuntu-ninjas, as only people with git permissions need access to the CI
~kubuntu-ci-admins are members of ~kubuntu-ninjas that are willing to help with developing the CI tooling and server administration.
Used to host the Kubuntu Updates, Backports and Experimental PPAs
Kubuntu Ninjas Yellow Belts is anyone who is training up to become a Kubuntu Ninja
The following teams only allow pseudo-membership and are used for organizational purposes. These teams should not be joined directly, but instead the team mentioned in brackets. When in doubt, check the members of a team. If ~kubuntu-members, ~kubuntu-ninjas or ~kubuntu-dev is a member, then the team likely is a pseudo-team and should not be joined directly.
These teams can be joined by anyone who wishes to take part in their mission.
"Patches are evil." - apachelogger around 2009
If you think this policy sounds a lot like a PITA then you are absolutely right and the policy works as intended.
Before creating a patch it needs to be evaluated if another approach might not be better suited. For example most default changes to KDE software's behavior can be carried out via kubuntu-settings. Please also note that additions to kubuntu-settings should generally be considered patches, and discussion with upstream beforehand is advised.
TL;DR: changes should be done upstream.
In general one should attempt to create patches 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.
Patches must not be taken from any bug tracker, without being reviewed by upstream or someone who is familiar with the source base.
Whenever upstream does not approve of a patch on the basis of technical problems, it must not be included or must be removed. There is no exception to this rule.
Patches should be sent to Debian where they are likely to be relevant.
Tiny patches that either provide platform integration or behavior adjustments. These patches should be brought to the attention of upstream.
Patches adding more than 25 source lines of code, or adding/removing/changing more than 2 functions, or changing the interface of a function, must be reviewed and approved by upstream before inclusion into Kubuntu. This is because the larger a patch is, the greater the risk of regression compared to upstream.
Patches adding more than 200 source lines of code, or adding/removing/changing more than 4 functions, or requiring public API changes must be done upstream, unless they are 100% necessary for Kubuntu, and would cause malfunction or bugs if not applied (language-pack integration would be such a case). Even then upstream needs to be made aware and at least approve the patch's existence.
When merging with Debian's packaging, each Kubuntu (and preferably Debian) patch must be reviewed with regards to upstreamability to KDE or Debian. If a patch qualifies, upstreaming it should be proposed to the affected upstream; TODO tasks to track progress on upstreaming should be created whenever necessary.
All patches that are not from upstream or Debian must be documented as per the Tagging Guidelines. In particular the fields Forwarded and Reviewed-by must be present and reference the upstreaming attempt and upstream reviewer respectively. If a patch does not have either, the Description should describe why it was not forwarded.
Unless a dep3 Description is present in the patch itself a reasonable descriptive changelog entry must be made in debian/changelog; detailing where the patch comes from (if not created by us), why the patch is needed, why it was implemented this way, and possibly additional notes about impact on other packages.
Any Kubuntu patch not containing the above information either must get the information added or will be removed! It is not expected of anyone to go around asking people for this information.
Patch names ought to denote their origin and purpose as precise as possible.
The general naming scheme is: <origin>_<description>.[patch|diff]. If a patch is obtained from a VCS or another distribution the original description should be preserved in order to enable third parties to trace the patch.
The patch name must be mentioned in the debian/changelog entry for easy greppability.
This policy explains when we create stable release updates for which releases.
TL;DR version: KDE SC (along with selected other KDE packages) may receive stable release updates in the form of patch-version releases (e.g. x.y.3) that bundle multiple bugfixes together. These updates are prepared in PPAs and then pushed to proposed for verification.
When: SRUs for bugs in misc KDE software ought to only be done if the bug is causing severe problems for a majority of our users. Plasma crashing on startup because of a bad plasmoid that is added by default would be such a case; Plasma crashing on startup because the user installed a random plasmoid from kde-apps is not. Users may prepare SRUs on their own for which we only take care of upload sponsorship.
When Not: All bugs in KDE software covered by the Kubuntu updates policy (see above) should not receive individual stable release updates, unless no more patch releases are planned. The only exception to this are bugs of considerable impact on the user's experience and bugs that were caused by us.
Requirements: Candidate bugs must be filed on Launchpad, clearly describe what the issue is and argue why the issue deserves to be considered important enough to receive a stable release update, as well as a pointer to the relevant upstream commit/bug/discussion. If the bug does not receive attention within one week it should be presented on the mailing list and IRC channel until someone comments.
Only the latest release forms a target for manual stable updates. Older releases must have testers available for all targeted releases before doing any work on the actual SRU. This is to prevent SRUs from dangling in proposed without hope of ever getting verified. Generally a SRU should address the issue in all supported releases between the devel series and the oldest target (e.g. current: 14.04, target: 13.04, additional targets: 13.10 [assuming .10 is still supported]). If testers cannot be found for all target releases the SRU can not be carried out.
This policy outlines special long term stable support for Kubuntu releases.
Long term support releases are created every 2 years. They offer substantially longer support than regular releases.
In particular long term support releases have the following boons:
Long term support releases are not excepted from other standing policy.
Whenever we have no policy for a specific matter listed here, the relevant upstream policy ought to be applied whenever possible. In particular all code ought to follow upstream policies with regards to style, licensing and documentation.