attn folk doing reviews.

[John Arbash Meinel]

Martin Pool wrote:
> On 22 Jan 2006, Robey Pointer <robey at lag.net> wrote:
> 
>>On 22 Jan 2006, at 14:50, Robert Collins wrote:
>>
>>
>>>Two things... what do you think of some review guidelines as an aid to
>>>memory on the wiki ? I think the peer review thing is working well,  
>>>but
>>>that will make it clear to folk submitting code what we are looking  
>>>for.
>>
>>I dunno if I agree that it's working that well. :(  Since so few  
>>people are allowed to vote, it can be hard to get enough attention to  
>>a patch to actually collect 2 votes.
> 
> 
> You're definitely allowed to vote -- indeed anyone is, assuming they've
> actually read the thing.
> 

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 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've been trying to handle community integration, but I'm only a single
+1, so stuff like Robey's changes have been falling through the cracks,
since I was waiting for a second +1.

I think we could also make a distinction based on how involved the
change is. If someone is submitting a small bugfix, then a single +1
could be sufficient (especially if it comes with a test case). Versus
more involved work.

> I think although at the moment we do pretty well at keeping code
> reviewed and test coverage high there is still a bit of a bottleneck
> feeling.  I'm open to suggestions.
> 

I also don't want my suggestions to end up as a politics game. I don't
want people to feel like they are not worthy, or being passed over.
Having a distinction between trusted sources as untrusted is a real-life
thing, and over time you can move from one category into another. But
each person would have a different feeling about where everyone else
(and themselves) belongs. Which is where it can get weird.

I don't want to get too far off in a philosophical tangent, but code
review is a little bit of a people problem.

John
=:->
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060124/234c5fd8/attachment.pgp