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]])