I'd like an accurate, visually pleasing way to count how many unreviewed revisions there are in trunk, for when I'm encouraging volunteer code review. TL;DR version: it would be great if someone fixed up RobLa's chart, corrected its errors, and put a chart generator in the CodeReview MediaWiki extension.

The JavaScript behind RobLa's CRStats chart http://toolserver.org/~robla/crstats/ gives me some current numbers. By inspecting http://toolserver.org/~robla/crstats/data/trunkall/crstatsdata.js I believe I see we have 279 revisions left to review in trunk.

But the CodeReview statistics page at https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki... mentions that there are 344 NEW revisions in /trunk . That's more than the 279 that Rob's script counts; which should I believe?

Rob believes the problem is with his script. He has checked to see whether the problem is that his report, run every night at midnight UTC, falls out of sync with the CodeReview statistics page; that's not it.

Rob says:

Bummer, it looks like my script.... I probably won't get around to fixing up the script, but I've got a couple ideas about how to fix it...

the details for those who care about what it would take to fix my script or just implement it correctly in PHP in MediaWiki. What throws my script off is that I'm calculating the revision history starting way back in history and moving forward, piecing together the history of code review from our revision log plus status changes. It used to be safe to assume that all revisions started life as "new", and then use the status changes to step each revision through the rest of the workflow. However, one new-ish feature of the CodeReview extension is the ability to automatically set the start state to "deferred" based on the path of the checkin, which means those changes never show up in the status change log. My initial hack was to step through twice: first time to determine the initial state (assuming that if initial state != final state, then final state was the actual initial state). A more correct approach is to just start at the end (where we have a correct accounting of state) and reconstruct states backwards.