Kubuntu/Policies

Approval of Policies

All policies must be approved by the Kubuntu Council.

Bug Triage

This policy outlines where bugs are tracked and what their primary states are.

Launchpad bugs have 5 primary states

• New: new bug, not looked at
• Invalid: not our bug, or because it is no bug, or because we do not consider it a bug...
• Confirmed: bug was confirmed by someone other than the reporter
• Triaged: bug cause has been identified and is ready for a developer to look at
• Fix Released: fix has been released to the archive

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.

Packaging Bugs

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.

Kubuntu Software Bugs

Bugs in Kubuntu specific software are, like packaging bugs, handled on Launchpad.

Upstream Software Bugs

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.

SRU and Backport Bugs

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.

Unmaintained Software Bugs

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.

Responses

To allow swift dealing with all common bugs, boilerplate bug comments are available at Kubuntu/BugTriage and may be used vigorously.

Dead Upstream ((NEW))

This policy outlines how to deal with software that is unmaintained upstream.

Characteristics

• There is no upstream bug tracker, or bugs are not being triaged in the upstream bug tracker.
• There is no VCS, or the VCS has not seen any feature or bug fix commits in >= 6 months.
• No new release have been published in >= 6 months.
• Upstream developers cannot be contacted or are not responding.

New Packages

A new package of software that has a dead upstream must not be uploaded to the archive. No exceptions.

Existing Packages

Existing packages of which upstream went AWOL have different approaches available, depending on the environment.

General Viability

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.

• Does the software start successfully (without crash or other malfunctions)?
• Is it likely that the software will continue to start in the forseeable future?
• Does the core functionality of the software work as expected?
• Are there no known bugs that hinder the core functionality of the software such that it would be rendered useless for more than half the potential users?
• Are there no known crashes that cause data loss?
• Is anyone on the team able and willing to assess the quality every once in a while, but at least every 6 months?
• Is it necessary that the software is kept in the archive (e.g. scripted plasma widgets: no)?
• Does the general amount of known bugs in the software seem of sufficiently marginal impact that we can distribute the software in good conscience?

Official KDE Software

Official KDE software is generally every piece of software that has an official VCS on KDE's infrastructure and/or uses KDE's bug tracker.

Before taking any actions regarding apparently unmaintained official 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.

Other Software

Software that is not managed on KDE's infrastructure 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.

Reference Bug

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.

INSERT_ADDITIONAL_INFORMATION_HERE

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

Patches

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).

Distribution

Unmaintained software must not be distributed by default. Short term exceptions 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.

Handlers ((NEW))

This policy outlines who can do what where when how why. It's primary purpose is to document people to poke for specific things.

• Source/Binary NEW Review: ~ubuntu-archive [liaison: Riddell, ScottK]
• Package Removal from Archive: ~ubuntu-archive [liaison: Riddell]
• SRU: ~ubuntu-sru [liaison: ScottK]
• Offical Backports: ~ubuntu-backports [liaison: ScottK]
• PPA Backports: ~kubuntu-ppa [liaison: yofel]
• KDE Upstream: [liaison: Riddell, shadeslayer, yofel, apachelogger]

High Impact Bugs ((NEW))

High impact bugs are bugs that:

• Require mentioning in Release Notes
• Must be attempted to be fixed for LTS releases

A bug is considered to have high impact if...

• the bug breaks core functionality of the application
  • OR the bug hinders the intended user experience of the core functionality (such as constantly popping up useless notifications)
  • OR the bug is causing substantial amounts of automated crash reports on errors.ubuntu (relative to the overall amount of crashes)
  • OR upstream requests the bug to be noted and resolved (i.e. considered high impact upstream)
• AND upstream is aware and investigating

Kubuntu Council ((NEW))

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.

Election Process ((TBD))

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

Kubuntu Teams ((NEW))

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.

~kubuntu-council

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.

• Requirements: Getting elected.

~kubuntu-dev

Kubuntu Developers are the people with upload rights to the official archive. This is limited to the packages inside the kubuntu package set.

• Requirements: Existing ~kubuntu-members member, survive an interview by ~kubuntu-dev, get accepted by >= 3 existing developers.
• Notes: Unlike ~kubuntu-members this team is all about technical knowledge as trust is already validated through membership in ~kubuntu-members. With the exception of core developers there is no proxy membership possible; each member must be individually accepted to assure the tightest possible control.

~kubuntu-members

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 [[Membership|Ubuntu Member].

• Requirements: Significant and sustained contributions (of any sort) to Kubuntu, love for Kubuntu; survival of an interview by ~kubuntu-council and existing ~kubuntu-members. ~kubuntu-council holds formal vote on whether to accept an applicant. While there is no precise period that we look for, it is rare for applications to be accepted from people contributing for less than 6 months.
• Notes: Members, while not having any upload or bug control permissions, are meant to be trustworthy and act in the best interest of the project. ~kubuntu-members consequently also are members of all other Kubuntu teams that do not have additional requirements other than trust.
• Renewal: Membership is granted life-long, however members need to renew their membership on launchpad ever 2 years. Failing to do so, you may contact the ~kubuntu-council to consider manually reinstating your membership. Every member of the ~kubuntu-council is given a veto vote, that when used will require you to re-apply for membership and undergo the membership interview.
• CoC: All ~kubuntu-members must adhere to the CodeOfConduct.
• Application: To apply for membership all you need to do is inform the ~kubuntu-members about your desire to become member and organize an IRC meeting with as many council members present as possible. Also see https://wiki.ubuntu.com/Membership/NewMember for general information.

~kubuntu-ninjas

Kubuntu Ninjas are the elite KDE software update packagers.

• Requirements: Trusted enough to not break PPAs and produce good enough quality for ~kubuntu-dev to approve for an archive upload.
• Notes: Ninjas can not directly push changes to ~kubuntu-packagers owned branches because those are the heart of our packaging and must only be changed by someone trusted enough to not have malicious intent.

~kubuntu-packagers

Used for bzr branches of our packaging

• kubuntu-members and ubuntu-core-dev can commit to this
• Members can be added at the discretion of a Kubuntu Council member where it eases entry into the community for new packagers
• Other teams can be added such as test bots

~kubuntu-ppa

Used to host the Kubuntu Updates, Backports and Experimental PPAs

• kubuntu-dev is a member
• kubuntu-ninjas is a member
• Other members can be added at the discretion of a Kubuntu Council member where it eases entry into the community for new packagers

Psuedo Teams

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.

• ~kubuntu-active [~kubuntu-members]
• ~kubuntu-kdesudo [~kubuntu-members]
• ~kubuntu-netbook [~kubuntu-ninjas] (note: should be changed to -members, however the team is pretty much deprecated)

Free-For-All Teams

These teams can be joined by anyone who wishes to take part in their mission.

• ~kubuntu-bugs
• ~kubuntu-users

Patching ((NEW))

"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.

Implementation

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.

Upstream vs. Downstream

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.

Category A Patch

Tiny patches that either provide platform integration or behavior adjustments. These patches should be brought to the attention of upstream.

Category B Patch

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.

Category D Patch

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.

Merging

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.

Documentation

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 Naming

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.

Examples:

• kubuntu_magic-unicorn.patch (own patch)
• upstream_fix-air-ejection.patch (upstream git commit)
• fedora_add_rainbow.patch (patch imported from fedora without changes)
• bko_remove-spaceship.patch (patch from a bugs.kde.org report)

The patch name must be mentioned in the debian/changelog entry for easy greppability.

Stable Updates

This policy explains when we create stable release updates for which releases.

KDE SC

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.

https://wiki.ubuntu.com/Kubuntu/UpdatesPolicy

Misc ((NEW))

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.

Long Term Support (LTS)

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:

• During the first 6 months after release, developers put additional emphasis on delivering stable updates.
• Monthly KDE software release backports are made available through the Kubuntu PPA for as long as supported by the native LTS software stack but no longer than 2 years.
• KDE security updates are offered to LTS releases through their respective security repository throughout the entire long term support duration.
• Developers can deliver stable release updates throughout the entire long term support duration, in accordance with our Stable Updates policy. Users may request an update once an upstream fix has become available.
• Upgrading from one LTS to the following LTS is supported, effectively reducing the amount of upgrades a user will have to conduct to one every 2 years or 2 every 4 years.
• High impact bugs always get tracked and addressed for LTS releases.

Long term support releases are not excepted from other standing policy.

Global Fallback

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.