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