Kubuntu Policies (for council consideration)

Jonathan Riddell jr at jriddell.org
Wed Feb 26 09:54:20 UTC 2014


On Tue, Feb 25, 2014 at 09:35:12AM +0100, Harald Sitter wrote:
> On Mon, Feb 24, 2014 at 5:55 PM, Jonathan Riddell <jr at jriddell.org> wrote:
> >> > 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.
> 
> - bzr qdiff --new $REMOTE
> - (review)
> - bzr merge $REMOTE
> 
> that seems considerably more convenient than:
> - bzr qlog
> - (find revisions that are different)
> - (review)
> 
> former even can be scripted easily?

That means new contributors will spend 6 months when we don't trust
them enough to commit directly, 6 months when they are blocking on
someone reviewing their work and 6 months when existing members have
to put in time to review it.

Community made software needs processes which allow contributors to be
brought in as soon as they are competant, otherwise they'll get
frustrated, feel sidelined and leave.

This is probably why MOTU is so inactive these days, if it takes 6
months to be allowed in, nobody would want to be part.

Jonathan



More information about the kubuntu-devel mailing list