http://korma.wmflabs.org/browser/gerrit_review_queue.html?page=3 lists "Josa" with 3 patchsets waiting for review.
But https://gerrit.wikimedia.org/r/#/q/status:open+project:mediawiki/extensions/Josa,n,z only lists 3 open patchsets all with CR=+1. Hence there are no unreviewed changesets.
(Checked on 2015-12-13 and 2015-12-15)
This seems to be more wide-spread than I thought hence I'm adding this to our Jan/Feb-2016 radar.
Currently the data isn't reliable to find older unreviewed changesets. Can this be investigated? Another example:
http://korma.wmflabs.org/browser/gerrit_review_queue.html?page=2 lists "deploy" on #12 today.
"Waiting for review" in the middle shows "deploy:1" for "Dec 2015".
But https://gerrit.wikimedia.org/r/#/q/status:open+project:operations/dumps/html/deploy,n,z shows only one changeset with one patchset which has received a CR+1 already in August 2015.
I do confirm the bug.
For the repo "deploy" our dash says there is 1 waiting for review but according to the data source this is being reviewed and got +1 by three different people
owl@atari:~$ mysql -u root dic_gerrit_mediawiki_5829
mysql> select * from issues where issue = 204964
-> ;
+--------+------------+--------+--------+------------------------------------+-------------+--------+------------+----------+--------------+---------------------+-------------+
| id | tracker_id | issue | type | summary | description | status | resolution | priority | submitted_by | submitted_on | assigned_to |
+--------+------------+--------+--------+------------------------------------+-------------+--------+------------+----------+--------------+---------------------+-------------+
| 215297 | 1317 | 204964 | review | htmldumper 0.1.0 with dependencies | | NEW | None | None | 183 | 2015-04-18 01:14:42 | 0 |
+--------+------------+--------+--------+------------------------------------+-------------+--------+------------+----------+--------------+---------------------+-------------+
1 row in set (0,13 sec)
mysql> select * from changes where issue_id=215297;
+---------+----------+-------------+-----------+-----------+------------+---------------------+
| id | issue_id | field | old_value | new_value | changed_by | changed_on |
+---------+----------+-------------+-----------+-----------+------------+---------------------+
| 2054694 | 215297 | Upload | 1 | | 183 | 2015-04-18 01:14:42 |
| 2054695 | 215297 | Code-Review | 1 | 1 | 929 | 2015-04-18 01:44:18 |
| 2054696 | 215297 | Code-Review | 1 | 1 | 284 | 2015-04-18 11:29:47 |
| 2054697 | 215297 | status | 1 | UPLOADED | 183 | 2015-04-18 01:14:42 |
| 2054698 | 215297 | status | | NEW | 183 | 2015-04-18 01:14:42 |
| 2141316 | 215297 | Code-Review | 1 | 1 | 183 | 2015-08-05 18:47:25 |
+---------+----------+-------------+-----------+-----------+------------+---------------------+
6 rows in set (0,00 sec)It seems I was wrong! I was talking with @Dicortazar and it seems the metric is right but it does not represent what we were expecting.
This metric shows the number of gerrit issues waiting for some action to be taken by the reviewer. So it is not the number of issues waiting to be attended.
My proposal is to replace the title for something more close to reality.
What do you think?
@Lcanasdiaz: <tl;dr> Pull request to fix this task created in https://github.com/Bitergia/mediawiki-dashboard/pull/78
Hah. So "Waiting for review" excludes CR-1 and CR-2 items (and also V-2?) and includes both CR=0 and CR+1 items. While I thought it only includes CR=0 items.
The desc of scr_ReviewsWaitingForReviewer_ts (which isn't visible anywhere, as far as I understand) even says so, now that I looked it up. :)
I think the current behavior makes sense to not only avoid rotting patches without review but also avoid rotting patches which have been +1ed but not merged yet.
Indeed, let's clarify strings instead (as mentioned but not followed up on in T39463#415660 already).
https://github.com/Bitergia/mediawiki-dashboard/pull/78 merged; waiting for deployment on korma before closing as fixed