The obvious problem with the 72 hour time limit is that it imposes unnecessary time limits, adding lots of to the complexity, chaos and stress - possibly a net-negative, but it's hard to say for sure.
That said, at least it's an actionable idea.
It's pretty clear to me that the inconvenience that's been avoided in this area by shooting down ideas rather than just taking action and working out the details as we go is equivalent to a meer fraction of the effort that's been put forth in the form of demanding a perfect solution and generally resisting change.
We should probably also not be setting the stakes so high, it's making the cost of failure unnecessarily expensive. One project should change their review and release strategy, and see if that can be worked out and fine tuned. Then we can apply those lessons to the code base in general. This is especially useful if a strategy is radically different than what we have now.
- Trevor
On Tue, May 31, 2011 at 12:37 PM, Max Semenik maxsem.wiki@gmail.com wrote:
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:
- 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