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
_______________________________________________
darcs-users mailing list
darcs-users@darcs.net
http://lists.osuosl.org/mailman/listinfo/darcs-users
