Last modified: 2014-08-19 22:56:15 UTC
On http://korma.wmflabs.org/browser/bugzilla_response_time.html under "Longest time without comment" there is https://bugzilla.wikimedia.org/show_bug.cgi?id=7886 on 3rd place with 2,719.6 days right now, but that ticket received several comments nine days ago. How often is that list supposed to get updated? Something stuck maybe?
Strange, I have gone through dozens of links in that list, and all of them seemed legit. I wonder whether the fact that the status of that report is REOPENED has anything to do with this. Marking as "High" not because of the minor problem, but for the possibility that REOPENED reports are treated differently.
Note that it has also Lowest priority, another factor to take it out from the list.
This bug is related to issues that shift from a component to another. We analize the issues by component so, when their component changes, we don't track it on the former component. We do it on the new one. Now, we have the same issue duplicated in our database. One in Search component that don't has info about the comments and new changes that were made; and the other on in CirrusSearch, which has the recent activity. That's why 7886 is been shown in the table. Because we're showing the issue, stored in our database, that don't have the latest comments. I've just removed from the database and on the next update, it should have been removed from the top list, too. In any case, we have to find ways to detect these kind of problems.
Thank you for the details. Moving bugs to another component is a relatively frequent action. Do you mean that every time this happens, we have a duplicated entry in Korma's database?
Yes, that's the point. I checked the database and currently, we only have 39 duplicated out of 46276 issues.
I forgot to mention that this number is so low because we regenerate the database from time to time.
Looks like this is FIXED now; item not listed anymore. Santiago: Is only this item "fixed", or is the general problem also fixed?
This is still (again?) a problem: The middle column lists bug 12360 (Implement an extension similar to the LifeMarks - on the Hebrew Wikipedia) which I commented on a few weeks ago.
(In reply to Andre Klapper from comment #8) > This is still (again?) a problem: > The middle column lists bug 12360 (Implement an extension similar to the > LifeMarks - on the Hebrew Wikipedia) which I commented on a few weeks ago. We fixed the problem with duplicated issues but we still have a problem when an issue is moved from a key project to a non key project, that is the case of bug 12360. We still have to think how to track these kind of changes. BTW, I removed that issue from the database. That means it will be removed from the database with the daily update.
(In reply to Santiago Dueñas from comment #9) > we still have a problem when an issue is moved from a key project to a non > key project. We still have to think how to track these kind of changes. https://bugzilla.wikimedia.org/show_bug.cgi?id=13090#c2 is another example with a comment from 2014-06-22, still listed in the "Longest time without comment" column.
The problem here is we only track those issues from the list of products and components (key projects) you gave us. When an issue is shifted to another product we cannot trace it. To be more specific, our tool retrieves issues using ULRs like: https://bugzilla.wikimedia.org/buglist.cgi?product=MediaWiki%20extensions&component=OAuth So, for instance, if an issue from OAuth is moved to "Extensions requests", that issue will not be listed anymore using the URL from above. The issue will be listed when requesting the issues from "Extensions requests" component. As we do not track this component, we can't know what has happened to that issue. I only found a solution for this and it's to crawl the whole Bugzilla, retrieve all issues and then, filter by key projects. The (huge) problem is it's time consuming. We will need more time on retrieving everyhing, filtering and measuring. I will talk during this week with Alvaro and let's see if we can find a better solution.
Disclaimer: I'm rather clueless & it's late, so this might be naive: (In reply to Santiago Dueñas from comment #11) > To be more specific, our tool retrieves issues using URLs like: > https://bugzilla.wikimedia.org/buglist. > cgi?product=MediaWiki%20extensions&component=OAuth > So, for instance, if an issue from OAuth is moved to "Extensions requests", > that issue will not be listed anymore using the URL from above. As you regularly update/sync the data in your database, how do you identify new (recently created) tickets created in a key project which is tracked? I assume by explicitly querying for tickets created since $time_of_last_db_sync, and then adding them to "your list"? No idea on performance or other side effects, just wondering: Compare the list of bug IDs for a tracked project {1, 4, 17} gathered yesterday with today's bug IDs from Bugzilla for that project {1, 17, 21}, in order to see that 1) bug #21 should also be tracked now for the project's stats, and that 2) bug #4 is not listed anymore and should be dropped from stats for this project? In other words, something like curl -X POST -H"Content-Type: text/xml" -d "<?xml version=\"1.0\" encoding=\"UTF-8\"?><methodCall><methodName>Bug.search</methodName><params><param><value><struct><member><name>component</name><value><array><data><string>Bugzilla</string></data></array></value></member><member><name>resolution</name><value><array><data><string></string></data></array></value></member><member><name>limit</name><value><array><data><value>0</value></data></array></value></member></struct></value></param></params></methodCall>" https://bugzilla.wikimedia.org/xmlrpc.cgi to get all open tickets for the "Bugzilla" component (query not tested, plus cool kids use JSON instead of XML), then extract all provided values for "id" nodes with your favorite parser, and compare that list against the list of bug IDs you have from the last time you ran that query? If that's not feasible (tool's architecture, Bugzilla sucks, etc.), a two-word "Sorry, nope!" reply here is very acceptable, to not waste your time. ;)
