On Mon, Jul 2, 2012 at 9:19 PM, Diederik van Liere dvanliere@gmail.com wrote:
I became curious with these statements regarding self-review (committer==reviewer) and so I ran a couple of queries against the gerrit database to see how often this occurs:
- For the puppet repo, 84.1% of the commits is self-reviewed.
Yeah, I don't think Ops is proud of this, but from my understanding, it's very difficult to develop for puppet without committing and seeing what happens. It's possible, but it's definitely not as productive.
- For the mediawiki core repo, 27.9% of the commits is self-reviewed.
How much of that is against master versus branches? Typically, cherry-picks and code in experimental branches is self-reviewed, but that number seems high for master. If there's a lot of that going on in master, I'd be curious as to which people are doing it.
- For the mediawiki extensions repos, 67.8% of the commits is self-reviewed.
Any way to break that out between deployed and not deployed? I know we haven't been as methodical about extensions as we've been about core, but I doubt the discrepancy is that large.
I think we need to take a step back from a tool-focused discussion and first hash out what our commit workflows are / should be. In particular:
Should there be one commit workflow that applies to all teams? Looking at current practise, the answer seems to be no but I am curious to hear what other people think. If the answer is that it's okay for different teams to have different commit workflows, then we should also look for tools that support this.
If self-review is so prevalent, does that mean that the pre-commit review workflow has failed?
Pre-commit review is what has made it possible for us to go to a bi-weekly deploy.
Rob