Hi everyone,
The JS-generated code review graphs are working again. The phase3 graphs now line up: http://toolserver.org/~bryan/stats/codereview-status-diff.png http://toolserver.org/~robla/crstats/crstats.trunkphase3.html
The minor discrepancy between those two graphs can be explained by a minor bug in mine. In my version, those revisions that span multiple trees (e.g. r103519 [1]) aren't counted. That seems to be a relatively small number of revs (mostly localization updates).
As for the "and...", it looks like code review in "/trunk" is quickly getting out of control: http://toolserver.org/~robla/crstats/crstats.trunkall.html
...at a pace far faster than I had realized. I'm hoping that a lot of the revisions in there are easily deferred, but if not, things are looking pretty grim for 1.19.
Rob
[1] https://www.mediawiki.org/wiki/Special:Code/MediaWiki/103519
On Thu, Nov 17, 2011 at 6:42 PM, Rob Lanphier robla@wikimedia.org wrote:
As for the "and...", it looks like code review in "/trunk" is quickly getting out of control: http://toolserver.org/~robla/crstats/crstats.trunkall.html
...at a pace far faster than I had realized. I'm hoping that a lot of the revisions in there are easily deferred, but if not, things are looking pretty grim for 1.19.
1.18 hasn't been released yet, so presumably we're still concentrating on solidifying the 1.18 release in CR. Per previous discussions about the 1.17 release delays I would have expected this to have gone *really fast* and been out the door around mid-October, within a few days of going live on the main sites.
It appears we have gotten to a "release candidate" as of last Friday, which is a good sign; is a final .0 release slated yet?
In the meantime we've got no upcoming 1.19 deployment pressure and nobody assigned to ongoing code review, so there's nothing to compel further action -- it's not surprising to me at all that it's falling behind.
-- brion
On Mon, Nov 21, 2011 at 3:52 PM, Brion Vibber brion@pobox.com wrote:
1.18 hasn't been released yet, so presumably we're still concentrating on solidifying the 1.18 release in CR. Per previous discussions about the 1.17 release delays I would have expected this to have gone *really fast* and been out the door around mid-October, within a few days of going live on the main sites.
/me reminds Brion IRL just how nutty mid-October was for WMF tech staff. :)
It's also Sam's first release, so it's taking a bit longer than if Tim were 100% focused on it. But the good news is that we're nearly there.
It appears we have gotten to a "release candidate" as of last Friday, which is a good sign; is a final .0 release slated yet?
We would probably push it out this week, but there's a security bug we're taking a look at.
In the meantime we've got no upcoming 1.19 deployment pressure and nobody assigned to ongoing code review, so there's nothing to compel further action -- it's not surprising to me at all that it's falling behind.
Brion and I spoke in real life right after this, which is highly unfair to the rest of you, but it was really efficient for us. Here's the gist: * I've already started a campaign to remind people of the 20% policy (http://www.mediawiki.org/wiki/20_percent ) * I'll also be sending out a revised target date for 1.19, based on looking at the updated numbers and how quickly we reviewed in some of our more determined review sprints, figuring in some time for a little regression during the holidays. * More people from Platform Engineering will be reinforcing that we want the next release to happen soon, even if that means other things (e.g. Git migration) lag as a result.
Not a perfect answer, but I think we're improving with each release. This time around, one key difference will be clearing the review backlog before branching, which, with any luck, means less backporting hell.
Rob
Speaking of 20% code review time, I've cleared my Tuesdays and stuck reminders in my calendar so I don't lose track of it in coming weeks. ;)
Please poke me during PST office hours with patches, bugs, and commits that need review or cleanup!
-- brion On Nov 21, 2011 6:41 PM, "Rob Lanphier" robla@wikimedia.org wrote:
On Mon, Nov 21, 2011 at 3:52 PM, Brion Vibber brion@pobox.com wrote:
1.18 hasn't been released yet, so presumably we're still concentrating on solidifying the 1.18 release in CR. Per previous discussions about the
1.17
release delays I would have expected this to have gone *really fast* and been out the door around mid-October, within a few days of going live on the main sites.
/me reminds Brion IRL just how nutty mid-October was for WMF tech staff. :)
It's also Sam's first release, so it's taking a bit longer than if Tim were 100% focused on it. But the good news is that we're nearly there.
It appears we have gotten to a "release candidate" as of last Friday,
which
is a good sign; is a final .0 release slated yet?
We would probably push it out this week, but there's a security bug we're taking a look at.
In the meantime we've got no upcoming 1.19 deployment pressure and nobody assigned to ongoing code review, so there's nothing to compel further action -- it's not surprising to me at all that it's falling behind.
Brion and I spoke in real life right after this, which is highly unfair to the rest of you, but it was really efficient for us. Here's the gist:
- I've already started a campaign to remind people of the 20% policy
(http://www.mediawiki.org/wiki/20_percent )
- I'll also be sending out a revised target date for 1.19, based on
looking at the updated numbers and how quickly we reviewed in some of our more determined review sprints, figuring in some time for a little regression during the holidays.
- More people from Platform Engineering will be reinforcing that we
want the next release to happen soon, even if that means other things (e.g. Git migration) lag as a result.
Not a perfect answer, but I think we're improving with each release. This time around, one key difference will be clearing the review backlog before branching, which, with any luck, means less backporting hell.
Rob
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 11/21/2011 09:41 PM, Rob Lanphier wrote:
On Mon, Nov 21, 2011 at 3:52 PM, Brion Vibber brion@pobox.com wrote:
...
In the meantime we've got no upcoming 1.19 deployment pressure and nobody assigned to ongoing code review, so there's nothing to compel further action -- it's not surprising to me at all that it's falling behind.
Brion and I spoke in real life right after this, which is highly unfair to the rest of you, but it was really efficient for us. Here's the gist:
- I've already started a campaign to remind people of the 20% policy
(http://www.mediawiki.org/wiki/20_percent )
- I'll also be sending out a revised target date for 1.19, based on
looking at the updated numbers and how quickly we reviewed in some of our more determined review sprints, figuring in some time for a little regression during the holidays.
- More people from Platform Engineering will be reinforcing that we
want the next release to happen soon, even if that means other things (e.g. Git migration) lag as a result.
Not a perfect answer, but I think we're improving with each release. This time around, one key difference will be clearing the review backlog before branching, which, with any luck, means less backporting hell.
Rob
Also, this year we've worked on other foundational support for training new code reviewers and encouraging developers to review code for the first time. In July and August we had two code review trainings. Guillaume and I are turning the artifacts from those trainings into improvements to the code review guidelines and educational materials on mediawiki.org -- see https://www.mediawiki.org/wiki/Volunteer_coordination_and_outreach/Training_... .
In the long run, I'd love to see a far greater proportion of MediaWiki's developers reviewing code (somewhat closer to the Launchpad model https://www.mediawiki.org/wiki/User:Sumanah/Launchpad-dev-process), which requires training.
So: If you are a MediaWiki developer, and you would like to be reviewing more code but aren't sure of your abilities, try coming into IRC when a more senior developer is there, per the chart at https://www.mediawiki.org/wiki/Development_process_improvement/20%25_policy#... , and suggest that you review a revision and then have your review metareviewed by him or her. Doing is the best way to learn.
wikitech-l@lists.wikimedia.org