On Tue, Nov 2, 2010 at 12:51 PM, Rob Lanphier robla@wikimedia.org wrote:
One discussion we had at the Hack-a-ton was about the continued frustration of getting features deployed to the WMF-operated sites.
Prior to Hack-a-ton, one short-term solution we started work on was consolidating the review queue into a single place: http://www.mediawiki.org/wiki/Review_queue
That page still needs some organization and a process around it to make sure that we're actually looking at the page. However, our discussion at Hack-a-ton made it clear that even if we have a well-tuned process there, we still have features rolling off the end of that conveyor belt onto the floor.
After review, some (but not all) of the features in the review queue then need to be reviewed for checking into the deployment branch. Our short term answer to that was the deployment queue: http://www.mediawiki.org/wiki/Deployment_queue
Even then, we're still not done. We have one more step, which is launching the feature on one or more wikis. We could also create another queue page for that. However, given the complicated workflow here, it seems that a wiki is the wrong tool to keep track of this.
Okay, maybe I'm missing something, but how about the following process:
1) Feature gets committed to trunk.
2) All commits in trunk get reviewed using Code Review, marking things deferred if they don't need review (e.g., extensions not used by Wikimedia).
3) Once all of trunk is reviewed, it's deployed, preferably at least once per week.
This is what we're aiming for, right? If extensions need review, it seems like the most logical way to handle that would be to mark recent commits to the extension in trunk as new, and post a comment asking people to review the whole extension. Reviewers are already routinely looking for all commits in Code Review marked "new", so this fits in nicely with the existing procedure.
I get the feeling you might be talking about an entirely different problem, though -- maybe I'm confused.