On Wed, Jun 1, 2011 at 1:43 AM, Brion Vibber brion@pobox.com wrote:
substantially broken, BECAUSE ***THEY'RE NOT USING IT*** FOR THINGS THAT ARE IMPORTANT TO THEM.
That's not correct -- the same code review tools are being used to look over and comment on those things, AND THEN THE DAMN THING ACTUALLY GETS MERGED TO THE DEPLOYMENT BRANCH BY SOMEBODY AND PUSHED TO PRODUCTION BY SOMEBODY.
Alright, we've had fun with all caps for a while, so let's focus on solutions now.
MZ says we need to move to a system with regular deployments, where regular is more than monthly and ideally weekly or bi-weekly. I completely agree with this, per the "spend a day per week or a week per month" argument. The discussion then turns into conflating releases and deployments, followed by some back and forth yelling about deadlines and CR processes.
So let me sketch how I see us getting there.
1. Get 1.18 reviewed 2a. Get 1.18 deployed and released 2b. At the same time, continue efforts to have code review catch up with SVN HEAD 3. Once we have reviewed everything up to HEAD (or up to a revision less than a week older than HEAD), deploy it to Wikimedia 4. Keep reviewing so the CR backlog doesn't grow, and deploy HEAD again in 1-2 weeks. Rinse and repeat.
There are a few caveats here, of course: * 2a and 2b largely compete for the time of the same developers * 3 (initial HEAD deployment) will probably be a bit hairy because it's a lot of code the first time. After that it's only 1-2 weeks' worth each time * For 4, we need to figure out a way to make CR actually happen in a regular and timely fashion
So a lot of it comes down to implementing a proper code review process, both for the one-off catch-up sprint (to 1.18, then to HEAD; we've done one of these before with 1.17) and for the day-to-day keep-up work. I think we may also need to make it clearer that reviewers (who, typically, are paid developers working on many other things) need to spend one-fifth of their time (i.e. a day per week for full-time employees) on code review. This is basically the "admins aren't watching Special:Unreviewedpages at all" problem that Happy-melon mentioned.
So mostly, I think our immediate problems are: * no agreed-upon strategy to tackle the problem (what do y'all think about mine?) * not enough man-hours spent on keeping up with new commits ** ...presumably because employed people aren't given the time to work on it and/or made to work on it ** ...and because some of our reviewers are college students working part-time (fortunately I'll graduate soon and have more time :D)
Thoughts?
Roan Kattouw (Catrope)