Kubuntu Policies (for council consideration)

[Harald Sitter]

On Tue, Feb 18, 2014 at 6:47 PM, Jonathan Riddell <jr at jriddell.org> wrote:
>
> 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.

What is the benefit of that?

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

^ IMHO we really should have a hard value there, if 6 months seems to
long then perhaps 3 might be more acceptable, but I think a lot of the
recent candidates had a hard time knowing when exactly their
contirbution was sustained enough. the significance of things are hard
to define anyway, but one hard value seems better than a requirement
jellyfish.

> 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

Indeed. There is a very discrete work flow for how one easily reviews
a branch. That's a merge, and adding people to pseudo teams at the
discretion of one council member is completely bypassing that. So, all
that does is make it very convenient for people to not easily review
the bzr branch at all, then upload, break things, giving me a
heartattack.

> "Patches should be sent to Debian where they are likely to be relevant."
>
> Why no Category C patches?

Because Category D is DANGER, so it had to be D and not C, perhaps it
should be renamed to "Category D(anger)" <- oh, anger also very much
applies. Much finesse right there.

> "language-pack integration would be such a case"  has upstream approved this? is there an upstream?

There's a number of upstreams involved, neither of which has approved
anything because we had no policy :P

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

^ I think reviewing Debian's patches is out of scope TBH. While nice,
it is completely pointless additional work we'd burden ourselfs with,
which in turn will lead to people being sloppy about it and then
retaining overall review quality at what we have right now with random
patches doing random things floating about randomly for no reason
whatsoever (e.g. the netbook favorites patch I recently ripped out
workspace)

HS