MediaWiki Bugzilla Report for May 03, 2010 - May 10, 2010
Status changes this week
Bugs NEW : 71 Bugs ASSIGNED : 7 Bugs REOPENED : 9 Bugs RESOLVED : 72
Total bugs still open: 4381
Resolutions for the week:
Bugs marked FIXED : 50 Bugs marked REMIND : 1 Bugs marked INVALID : 5 Bugs marked DUPLICATE : 8 Bugs marked WONTFIX : 6 Bugs marked WORKSFORME : 2 Bugs marked LATER : 1 Bugs marked MOVED : 0
Specific Product/Component Resolutions & User Metrics
New Bugs Per Component
Site requests 6 General/Unknown 3 UsabilityInitiative 2 SemanticForms 2 Vector Skin 2
New Bugs Per Product
MediaWiki 13 Wikimedia 8 MediaWiki extensions 11 mwdumper 1 Wikipedia Mobile 2
Top 5 Bug Resolvers
jeluf [AT] gmx.de 13 agarrett [AT] wikimedia.org 8 innocentkiller [AT] gmail.com 6 cbass [AT] wikimedia.org 5 hartman [AT] videolan.org 4
Could be CodeReview data easily merged here? Would be cool having (for phase3) the number of new revisions, how many revisions are marked new since the latest release, the number of fixmes... That would be a few simple of sql queries, so I don't think there would be issues on it (although CodeReview has fewer indexes than I expected). OTOH a new mysql account to read the code_rev table may be appropiate, and I don't have access to svn-private, so someone with appropiate rights would need to look into it.
I think that would be a nice status update. If someone can write the code .. I'll happily dig up where this report lives.
--tomasz
On May 10, 2010, at 6:59 AM, Platonides wrote:
Could be CodeReview data easily merged here? Would be cool having (for phase3) the number of new revisions, how many revisions are marked new since the latest release, the number of fixmes... That would be a few simple of sql queries, so I don't think there would be issues on it (although CodeReview has fewer indexes than I expected). OTOH a new mysql account to read the code_rev table may be appropiate, and I don't have access to svn-private, so someone with appropiate rights would need to look into it.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Tomasz Finc wrote:
I think that would be a nice status update. If someone can write the code .. I'll happily dig up where this report lives.
--tomasz
The report is generated from isidore:/home/reporter/bugzilla_report.php The script living at svn-private/wmf/reports
It probably isn't using the mediawiki database class but direct mysql calls.
The code to add would be similar to this:
$epoch = "20090430041100"; #Date of r50060, branching 1.15 foreach( array('', 'new', 'fixme') as $status) { if ($status == '') { $extra = ""; $extra2 = ""; } else { $extra = " AND cr_status = '$status'"; $extra2 = " tagged $status"; } $n = Sql_query( "SELECT (SELECT COUNT(*) FROM code_rev WHERE cr_repo_id=1 AND cr_timestamp >= '$epoch' $extra AND cr_path LIKE "/trunk/phase3%") + (SELECT COUNT(*) FROM code_rev WHERE cr_repo_id=1 AND cr_timestamp >= '$epoch' $extra AND cr_path="/trunk") + (SELECT COUNT(*) FROM code_rev WHERE cr_repo_id=1 AND cr_timestamp >= '$epoch' $extra AND cr_path="/") );
echo "$n revisions$extra2 since $epoch\n" /* Get values from last week */ echo ($n - $old[$status]) . " new revisions$extra2 since last week\n"; }
2010/5/12 Platonides Platonides@gmail.com:
$n = Sql_query( "SELECT (SELECT COUNT(*) FROM code_rev WHERE cr_repo_id=1 AND cr_timestamp >= '$epoch' $extra AND cr_path LIKE "/trunk/phase3%") + (SELECT COUNT(*) FROM code_rev WHERE cr_repo_id=1 AND cr_timestamp >= '$epoch' $extra AND cr_path="/trunk") + (SELECT COUNT(*) FROM code_rev WHERE cr_repo_id=1 AND cr_timestamp >= '$epoch' $extra AND cr_path="/") );
This query won't work. Each revision has multiple entries on the code_rev table, one for each path. This means you need to use COUNT(DISTINCT cr_id) and need to drop the second and third subqueries. You also need to use single quotes throughout the query, because it's wrapped in double quotes. Furthermore, the correct function name is mysql_query():
$n = mysql_query( "SELECT COUNT(DISTINCT cr_id) FROM code_rev WHERE cr_repo_id=1 AND cr_timestamp >= '$epoch' $extra AND cr_path LIKE '/trunk/phase3%'");
Roan Kattouw (Catrope)
Roan Kattouw wrote:
2010/5/12 Platonides Platonides@gmail.com:
$n = Sql_query( "SELECT (SELECT COUNT(*) FROM code_rev WHERE
cr_repo_id=1 AND cr_timestamp >= '$epoch' $extra AND cr_path LIKE "/trunk/phase3%") + (SELECT COUNT(*) FROM code_rev WHERE cr_repo_id=1 AND cr_timestamp >= '$epoch' $extra AND cr_path="/trunk") + (SELECT COUNT(*) FROM code_rev WHERE cr_repo_id=1 AND cr_timestamp >= '$epoch' $extra AND cr_path="/") );
This query won't work. Each revision has multiple entries on the code_rev table, one for each path. This means you need to use COUNT(DISTINCT cr_id) and need to drop the second and third subqueries.
That doesn't match the expected behavior from the SQL file. Are you sure it works like that? Since there's a primary key on (cr_repo_id, cr_id), you can't have multiple entries [on the same repo] with the same cr_id. cr_path contains the shortest common parent for all the involved files. Thus, a change to /trunk/phase3 will store only /trunk if it also applies to a branch. Or / (or is it ''?) if it also changed something at the repository root, which is really unlikely.
Feel free to drop the check for /, perform the sum in php, and so on. This was not intended as a final implementation.
You also need to use single quotes throughout the query, because it's wrapped in double quotes.
Good point. I thought I was using single quotes on the whole query, I missed the cr_path.
Furthermore, the correct function name is mysql_query():
$n = mysql_query( "SELECT COUNT(DISTINCT cr_id) FROM code_rev WHERE cr_repo_id=1 AND cr_timestamp >= '$epoch' $extra AND cr_path LIKE '/trunk/phase3%'");
Opening the connection to the database and passing it to mysql_query would be a good idea, too. :) I didn't want to go into the detail of db connection so I put it in terms of a generic Sql_query() call (initially it was, Sql query -> SELECT...)
2010/5/13 Platonides Platonides@gmail.com:
That doesn't match the expected behavior from the SQL file. Are you sure it works like that? Since there's a primary key on (cr_repo_id, cr_id), you can't have multiple entries [on the same repo] with the same cr_id. cr_path contains the shortest common parent for all the involved files. Thus, a change to /trunk/phase3 will store only /trunk if it also applies to a branch. Or / (or is it ''?) if it also changed something at the repository root, which is really unlikely.
You're right, my apologies. That query was meant to run on the code_paths table instead:
SELECT COUNT(DISTINCT cr_id) FROM code_paths, code_rev WHERE cr_repo_id=cp_repo_id AND cr_id = cp_rev_id AND cp_repo_id=1 AND cr_timestamp >= '$epoch' $extra AND cp_path = '/trunk/phase3'
Could probably drop the DISTINCT as well, but it's early morning as I write this so I'm not sure.
Roan Kattouw (Catrope)
wikitech-l@lists.wikimedia.org