User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030212 Phoenix/0.5 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030212 Phoenix/0.5 Here is a script for bug counts vs. time. By using the bugs_activity table, no cron job is required, and the queries can be endlessly modified. Unfortunately, the work was commissioned recently (Nov 2002) against a 2.10 installation. It should still work with many later versions. Many kudos to Gervase Markham for his integration of bug 92676 into the mainline. Excellent work. I though 92676 was too server abusive to make available on bugzilla.mozilla.org, but it seems I have to try again. :-) This one requires more data to be drawn from the database into perl, especially if the retroactive flag isn't set, where the script fetches parts of *every* row of tables bugs and most of bugs_activity. Sadly, even with the retroactive flag, the non-enum filter items needlessly force a fetch-every-row. :-( This could be improved. Unfortunately, my time is running out, and I should post it before it rots further. Many people should find it useful as is. As before certain queries on certain datasets could be more efficient by doing the counting with "group by" statements on the SQL server. This can be hard to predict, difficult to code, and expensive if optimized incorrectly. Still, avoiding an all row fetch of the bugs table would be good, even if it meant hundreds of queries. Nonetheless, this script will have to do for an inital release. Of greater shame is how this script doesn't use the SQL push and pop functions of globals.pl because it needs to fetch from two queries simultaneously. Thus, it doesn't honor the shadow database for the second query, although that would not be so hard to add. Incidentally, the patch merely includes the two new files. Adding links from the other pages is left as an exercise for the installer. Managers should be cautioned that a perfect picture of history is an elusive item. Certain behaviors like changing the priority of bugs during or after resolution, will affect the reports if filtered by priority. I am not saying the script has bugs, but its counts can be suprising. For example, it is possible to filter on severity and have a large open rate, a zero close rate, and yet see no change in the bug count. Don't be fooled! Ohhh yeah.... Happy Valentines Day. Reproducible: Always Steps to Reproduce: 1. Install the script. 2. Chart some data 3. Give your manager an orgasm.
This code generates the reports for a bugzilla 2.10 installation. It should work on newer ones as well. Linking to the new scripts is an exercise for the installer.
Assignee: endico → gerv
Status: UNCONFIRMED → NEW
Component: Query/Bug List → Reporting/Charting
Ever confirmed: true
Whoa. This is way cool. :-) I don't know when I'll get around to integrating this, if ever, but you get maximum points for implementing it... Gerv
Very cool. This just screams for the ability to define a query like this and have either the data stored as a dataset like any other in Gerv's general chants or else let these queries themselves be stored so they can be plotted right along with Gerv's.
Er... I'm not quite sure what Joel is smoking :-) These are snapshots of the state of the database in time, and are therefore far more akin to generic reporting than generic charting. So "storing datasets" makes no sense (unless you mean a bookmark to the query), and they can't be "plotted alongside mine", because they aren't graphs. :-) Or have I misunderstood you? Gerv
You must have.... :-) Rick is retroactively producing a set of datapoints over time. Gerv produces sets of datapoints over time. Why would I not be able to plot them on the same graph? There is no reason they have to be displayed in tabular form only.
Hmm. OK, now I look at it again, it does make a bit more sense. But having it all on the same graph in Bugzilla would be very tricky. Another job for Excel or OpenOffice.org Calc, methinks :-) Gerv
Any update folks....seems a dam cool feature to have in...
Since I don't have the time to work on this and Gerv doesn't believe it should be done, this needs a volunteer.
(In reply to comment #11) > Since I don't have the time to work on this and Gerv doesn't believe it should > be done, this needs a volunteer. very nice indeed. Given the passing of 2 years perhaps it's value can be reassessed.
You need to log in before you can comment on or make changes to this bug.