Kubuntu Policies (for council consideration)

Jonathan Riddell jr at jriddell.org
Tue Feb 18 17:47:57 UTC 2014


Thanks for working on this, I've read it over and have made the following changes as suggestions.  See also questions on patches.

''Upstream bugs that do not request a SRU/backport of an existing fix are to be closed as '''Invalid'''; without exception.''
↓
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.


~kubuntu-members -> changed 6 months to "significant and sustained"

It is useful to be able to add people to these teams where it eases beginning to contribute to Kubuntu (thinking sgclark currently), bzr branches can be easily reviewed.
~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 

"Patches should be sent to Debian where they are likely to be relevant."

Why no Category C patches?
"language-pack integration would be such a case"  has upstream approved this? is there an upstream?

Merging
"When merging with Debian's packaging, each Kubuntu (and preferably Debian) patch must be reviewed"

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

Jonathan



More information about the kubuntu-devel mailing list