On Tue, Nov 2, 2010 at 12:51 PM, Rob Lanphier <robla(a)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.