On Thu, Mar 24, 2011 at 2:00 PM, Roan Kattouw <roan.katt...@gmail.com> wrote: > 2) Resolving conflicts between patches is done by reviewers when they > apply them instead of being conveniently outsourced to the > author-committers
If there's a conflict, the reviewer can ask the patch submitter to submit a new version with the conflict resolved. I had this happen to me for one of the patches I submitted to Mozilla. I was then asked to submit an interdiff to highlight what had changed in my new version, so that the reviewer didn't have to re-review the parts of the patch that didn't change. Review-then-commit systems tend to place much more of a burden on the submitter and less on the reviewer. > 3) If review capacity is low, patches don't get committed, their > authors bug reviewers a few times, give up, get demotivated and leave > the project This is the major issue. We need to get review sorted out on a organizational basis before we start considering shaking anything up. At Mozilla, the way it works (in my experience) is you ask a suitable person for review, and they reliably respond to you within a few days. I'm sure that for large patchsets it's harder than for the trivial patches I submit, but the system clearly works. We need to have a pool of reviewers who are responsible for setting aside their other responsibilities to whatever extent is necessary to get new code adequately reviewed (which could just mean reverting it if it has too many problems). _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
