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(a)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:
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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l