Tim Starling wrote: > In the last week, I've been reviewing extensions that were written > years ago, and were never properly looked at. I don't think it's > appropriate to measure success in code review solely by the number of > "new" revisions after the last branch point. > > Code review of self-contained projects becomes easier the longer you > leave it. This is because you can avoid reading code which was > superseded, and because it becomes possible to read whole files > instead of diffs. So maintaining some amount of review backlog means > that you can make more efficient use of reviewer time.
I agree. But that only works for extensions since: * They are self-contained * They are relatively small * They are not deployment blockers And still they are harder to fix months later when the author has moved on (think in the poolcounterd bug). I don't think that would work as well for core MediaWiki, albeit it may be feasible for not-so-big features with a kill switch. Large commits changing many files would need a branch to be reviewable in a set. However, our problem with branches is that it removes almost all peer review and testing, and merges are likely to introduce subtle bugs. The late review drawbacks are also there. > Our current system links version control with review. After a > developer has done a substantial amount of work, they commit it. That > doesn't necessarily mean they want their code looked at at that point, > they may just want to make a backup. How do you propose to fix it? The committer deferring its own revision? It may be worth making a list of review requests at mediawiki. _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
