Kubuntu Policies (for council consideration)
Harald Sitter
apachelogger at ubuntu.com
Mon Feb 17 16:47:54 UTC 2014
Salut,
TLDR: request for the council to discuss and vote on new policies document.
The past couple of weeks I worked towards rewriting and updating our
current Kubuntu specific policies of which [1] is the result.
As with all policies all of it now requires approval by the Kubuntu
Council which I propose should be done on the list as meetings are
tedious to organize and some of the policies might require length
discussions (or hopefully not).
For the better part these policies are either aligned with current
practise that we had not previously put into written policy or solve
problems to which we never had a best practise solution. Completely
new policies are marked with ((NEW)), all others were derived from
existing policies.
New key policies:
* Dead Upstream - how to deal with software that is unmaintained upstream.
* Handlers - list of contact people for various important things
(requested by JR).
* Kubuntu Council - I did not find a standing policy document on the
council, one may feel free to enhance it.
* Kubuntu Teams - describing all Kubuntu teams, how to get it and what
they are there for (requested by JR)
* Patching - while originally written 3 years ago the patch policy was
never actually approved so this is a slighly refined version of the
previous one. however equally restrictive in what patches can or
cannot do.
* Stable Updates/Misc - when one may SRU software that is not covered
by our patch-update-exception (primarily KDE SC), it seeks to minimize
the amount of wasted time on SRUs that won't get verified.
* Long Term Support - outlines what sets an LTS release apart from
other releases specifically for Kubuntu.
Additionaly the bug triage policy has been changed to reflect what I
did for the past year or two (primarily streamlining over the previous
policy).
The code style policy from Lucid has been dropped and instead a global
fallback policy was introduced making the upstream policies our
policies unless we have a policy of our own (e.g. upstream code style
and licensing policies apply now - again, what we have practised for
years anyway).
[1] https://wiki.ubuntu.com/Kubuntu/Policies
HS
More information about the kubuntu-devel
mailing list