Kubuntu Policies (for council consideration)

[Jonathan Riddell]

On Wed, Feb 19, 2014 at 02:05:26PM +0100, Harald Sitter wrote:
> > 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?

So that bugs which need to be tracked for the release can be easily tracked.

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

I'd prefer 3 months because I don't want to make it too hard to get
membership, we should make it pretty easy to make people feel part of
the gang.  On the other hand I just checked Ubuntu which does say 6
months https://wiki.ubuntu.com/Membership/NewMember

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

it's far more hassle to merge in a new branch, doing that 50 times makes a lot of hassle.

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

that's why I say preferably, it's not a hard requirement, but it's not
uncommon to review Debian patches and find ones which should go
upstream.

Jonathan