Subject: Pragmatism

From: Daniel van Vugt <[email-masked]>
Date: Tue, 23 Apr 2013 10:02:52 +0800

All,

I've noticed that we're usually split in style within mir-team. Though 
it often seems a little skewed as some of the team is working on 
projects outside of lp:mir so do not express as many opinions.

Being split, it's clear that a unanimity/veto approach to code reviews 
will not work. So I suggest:

A proposal requires two approvals to land. Opposing reviews should be 
considered by those who Approve and a final decision made by Approvers. 
Those who oppose a proposal have the right to have their position 
considered by those who approve it. However disapproval should not 
always be a veto. This should apply to lp:mir.

Further to recent experience, I think it's inappropriate to apply the 
same rules when proposing a merge into someone's personal branch. You 
should not be able to force the owner of a branch to accept changes that 
he does not want his name on.

We're not going to find unanimity very often. So I would hope we can at 
least agree on a basic approach to breaking the regular deadlocks and 
getting code landed. I'm sure we're all tired of iterating the same 
branches week after week.

- Daniel

---

From: Robert Ancell <[email-masked]>
Date: Tue, 23 Apr 2013 16:41:46 +1200

On 23/04/13 14:02, Daniel van Vugt wrote:
> I've noticed that we're usually split in style within mir-team.

When it comes to style the rules are:
1. Follow the style guide (lp:mir guides/)
2. Follow existing code style

The current style may not match each of us prefer but that's life.
Proposing style changes is fine, but please don't delay functionality
changes with style changes.

--Robert