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/MediaWik…
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.
--
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation