attn folk doing reviews.

Robert Collins robertc at robertcollins.net
Wed Jan 25 02:16:48 GMT 2006


On Tue, 2006-01-24 at 10:16 -0600, John Arbash Meinel wrote:

> I would like to clarify the voting procedure then. At present, we have
> been using the rule:
> 
> If a main developer submits code, that automatically has one +1, so we
> only need 1 other main developer to review it to get into bzr.dev.
> Should we not be doing this? Should it always be 2 people other than the
> developer who review it before it gets in?

I think that we have roughly the idea of 'committers' in centralised
VCS's. In the process we ironed out, the gatekeeper policy is 'any two
committers' reach consensus -> it can be committed.

This means that yes, its easier for a committer to get code in (one +1),
but thats entirely natural - and I'd expect that list of committers to
grow - we have a bunch of great talent here. 

At martins request I'm setting up PQM for bzr.dev, so the committer term
will imply 'can commit straight to bzr.dev' - and I think its
appropriate to have the physical access, and the trust to not commit
silly things linked.

> I don't have a problem if we switch to a slightly more loose definition.
> Where we have patches submitted by people who don't contribute often,
> versus patches from people who have been with us for a long time (like
> Robey, Alexander, etc.).
> Infrequent submitters would need a double +1, while long-term submitters
> would only need a single +1, since they are wise enough not to request a
>  review of code they would not be happy with.
> Alternatively, everyone needs a double +1. But that starts to cause a
> big bottleneck. Since we don't have that many reviewers. (I think we
> have had maybe 6 people do reviews, so require 2 is 1/3rd of all reviewers)

I think Martin is right that sufficiently trivial stuff only needs a
single +1 - and I trust anyone that is a 'committer' - that is that
currently has an integration branch Martin pull from 'blindly', and that
will get PQM access immediately it comes online, to judge trivial vs
non.

Because - it is a people problem, and trusting folk is how you delegate
and scale things out.

Rob


-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060125/ac835157/attachment.pgp 


More information about the bazaar mailing list