On 31.05.2011, 22:41 Rob wrote: > So, there's a number of possible solutions to this problem. These are > independent suggestions, but any of these might help: > 1. We say that a commit has some fixed window (e.g. 72 hours) to get > reviewed, or else it is subject to automatic reversion. This will > motivate committers to make sure they have a reviewer lined up, and > make it clear that, if their code gets reverted, it's nothing > personal...it's just our process. > 2. We encourage committers to identify who will be reviewing their > code as part of their commit comment. That way, we have an identified > person who has license to revert if they don't understand the code.
Social problems are hard to fix using technical means. What will happen if someone approves a revision that later turns out to be defective, off with their head? "OMG my commit will be wasted in 20 minutes! Heeelponeone" is not the best scenario for clear thinking. Time pressure might result in people reviewing stuff they're less familiar with, and reviews being done in a haste, so CR quality will suffer. Although I'm not a biggest fan of rushing towards DVCS, the distributed heavily-branched model where mainline is supported only through merges from committed-then-reviewed branches looks far more superior to me. This way, we will also be able to push stuff to WMF more often as there will be no unreviwewed or unfinished code in trunk. -- Best regards, Max Semenik ([[User:MaxSem]]) _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
