On 23/03/11 12:05, Rob Lanphier wrote:
If our code review system was working smoothly, I wouldn't mind delaying this. However, it's pretty clear that code reviews aren't keeping pace (be sure to look at revisions marked "new" in trunk): http://toolserver.org/~robla/crstats/crstats.trunkall.html
I believe that once the reviewers get the hang of Git, they'll be more efficient, and be more capable of keeping up. I think paired with Neil's proposal[1] that we switch to pre-commit reviews, and we might actually be able to get back on a regular release cycle.
What proportion of a reviewer's time do you suppose is spent battling with Subversion? I thought most of it was just spent reading code.
If you want someone to dig a hole faster, you don't buy them a nicer-looking shovel. I think we have to look at the benefits of Git carefully, and to weigh it against the costs, both of conversion and ongoing.
I think our focus at the moment should be on deployment of extensions and core features from the 1.17 branch to Wikimedia. We have heard on several occasions that it is the delay between code commit and deployment, and the difficulty in getting things deployed, which is disheartening for developers who come to us from the Wikimedia community. I'm not so concerned about the backlog of trunk reviews. We cleared it before, so we can clear it again.
-- Tim Starling