On Wed, Jun 1, 2011 at 12:38 PM, Rob Lanphier <ro...@wikimedia.org> wrote: > The genesis of the 72-hour idea was our discussion about what is > stopping us from pre-commit review. The set of us in the office > discussing this felt it was pretty much just a tools issue; from a > policy point of view, we think it makes sense. Given that the 72-hour > rule is less severe than pre-commit review, do you believe that our > original premise is flawed (i.e. requiring pre-commit review is a bad > idea)?
The problem isn't reverting commits that are bad, it's reverting commits solely because they haven't been reviewed. In a pre-commit review system, the equivalent to the proposed 72-hour rule would be letting unreviewed code languish without comment. Both of these are bad things. The point is, people's code should only be rejected with some specific reason that either a) lets them fix it and resubmit, or b) tells them definitively that it's not wanted and they shouldn't waste further effort or hope on the project. Whether you're using review-then-commit or commit-then-review, one of the most demoralizing things you can do to a volunteer's contributions is say "nobody cares enough to provide any feedback on your code, so we're just going to reject it by default". Of course, all this requires time spent reviewing. It used to be that we had enough time in practice, even though volunteers greatly outnumbered paid staff. Now we seem to have a comparable number of paid staff and volunteers, so it seems clear that Wikimedia could find enough time if it wanted. But apparently Wikimedia's tech leadership feels it's more important to work on projects Wikimedia has a specific interest in, than to ensure that volunteer code is reviewed and deployed speedily and reliably. So the latter doesn't happen. On Wed, Jun 1, 2011 at 2:01 PM, Trevor Parscal <tpars...@wikimedia.org> wrote: > I believe the way forward involves using pre-commit review, requiring test > coverage to pass review, and developers working in branches at all times. > SVN may be a pita when it comes to branches, but that's a solvable problem. So then what happens if volunteers' contributions aren't reviewed promptly? In commit-then-review, they sit in trunk for months, by which point they're practically impossible to revert, so someone has to review them no matter what. In review-then-commit, they just never get committed, so they bitrot and are never used. The latter is incomparably more damaging to volunteers' willingness to participate. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
