On Thu, Aug 14, 2008 at 6:46 PM, Robert Godfrey <[EMAIL PROTECTED]> wrote:
> But the likelihood is that instead you'd get a load of JIRAs with > patches on that no-one reviews because they are lazy :-) But then there's the impetus for the owner to nudge a reviewer, and there's also social pressure to not hold up the other person by reviewing promptly and properly. I've seen review-then-commit work well as normal process in other projects (eg. GDB) where you have a largeish number of developers, and as a 'coming up for release' thing in projects where you have a smaller number of developers (eg. GNOME, Red Carpet). I've never seen commit-then-review work for any length of time, there's an initial flurry and then it dies down as people go on holiday, get interrupted or just get busy. We were doing commit-then-review before, and AFAICT, the review part just didn't happen all that much. > I think that if we as a group are good at enforcing the review phase > then we should be able to make this process workable. Producing > automated reports for number of unreviewed commits - plus a summary of > how many reviews each developer has done in the past month should I > think be sufficient to keep the number of unreviewed changes down to a > minimum. Reports work, but as we've seen with the existing process, actions are frequently left to languish on the "todo list". Even taking into account the synchronous nature of the review process we had, I still don't believe that people will do it. Automated reports are likely to be met with a "oh, yeah, I should do that, sorry...", but since we're responsible for reviewing things as a project it's unlikely that anybody will actually take personal ownership of that. - Aidan -- Apache Qpid - World Domination through Advanced Message Queueing http://cwiki.apache.org/qpid "Nine-tenths of wisdom consists in being wise in time." - Theodore Roosevelt
