Patch and vote procedure

[Martin Pool]

On 16 Oct 2006, Lachlan Patrick <loki at research.canon.com.au> wrote:

> I'm wondering what procedures people use to co-ordinate merging of
> patches in a decentralised version control system. Clearly it's not as
> simple as CVS's central repository model where every pushes changes into
> it at will.

Well, you can just set up a shared branch and all commit in to that.
We're making it more complicated because we want code review and
enforced testing, rather than because of the tool.

> What I've gleaned from lurking on this list is that people post a bzr
> diff to the list and there's some formal voting mechanism whereby +1
> indicates a vote in favour of a patch or a suggested change, and some
> number of votes is needed to carry that into force. I presume when those
> votes are gained there's a person controlling the 'official repository'
> who does a bzr merge with the patch to integrate the change.

It's only semi-formal; the numbers are just shorthand for thumbs
up/down.  The criteria include correctness, test coverage, and design
and code clarity.  They are described a bit in the HACKING file.

Several of us can send a merge to PQM, the Patch Queue Manager program.
That does the final merge, then checks that the test suite passes, which
makes it hard for people to cheat.  It notifies the person if the test
was successful or not, and sends mail to bazaar-commits if it was.

This works pretty well at getting reviews.  I feel like we could still
do with better process or tools for making sure things get reviewed and
not dropped - we need to scan a lot of mail to see which things still
need review vs being already either merged or withdrawn for more work.
On the whole it works pretty well.  In particular bzr.dev very rarely
regresses.

-- 
Martin