[darcs-users] how to stimulate code review

Simon Michael simon at joyful.com
Tue Aug 31 22:07:23 UTC 2010


As often, I have to prefix this with "from the armchair". But FWIW the recent soul-searching about code review, testing, 
benchmarking etc. interests me and makes me want to contribute to darcs. Maybe that's true for others too.

I was thinking about code review. I think we could agree that review of changes going in to darcs is a good thing, if it 
happens. All other things being equal.

There's a perception that getting sufficient code review for darcs has been a problem. I haven't actually measured that, 
but I believe it. Joe Darcs Hacker says: it slows me down, it blocks progress, we can't make it happen so we must 
abandon it as a requirement.

Wouldn't it be a good idea to "wear the hair shirt" here. An example:

  - no patch gets accepted without review. "review" means an agreed-upon definition, eg "has been signed off on the mail 
list by at least one trusted developer".
  - ultimate responsibility for getting reviewed lies with the patch submitter.
  - there are no exceptions.

We may have tried this before, and perhaps it seemed to fail. But I don't think we ever did it to the max. I think if we 
did, we'd first see progress grind to a halt, then we as a community would be *forced* to make the other changes 
necessary to make it work. That's the value of the discipline.

Also, I don't think we've had the incentives lined up right. There's (only ?) one strong incentive we have to offer 
darcs hackers, which is: accepting their code into trunk. I think we should make more use of that.

Making patch submitters responsible for getting reviewed will, I believe, encourage patches designed for easy review, 
discourage building up a backlog of unreviewed work, encourage more exchange of reviews (I'll review yours so you'll 
review mine), encourage process and tool refinement, and so on.

-Simon




More information about the darcs-users mailing list