Last Comment Bug 193177 - new report print bug counts and changes vs. time
: new report print bug counts and changes vs. time
Status: NEW
:
Product: Bugzilla
Classification: Server Software
Component: Reporting/Charting (show other bugs)
: unspecified
: All Linux
: -- enhancement with 3 votes (vote)
: ---
Assigned To: charting
: default-qa
:
Mentors:
http://fdd.com/software/bugzilla/
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2003-02-13 10:12 PST by Rick Dean
Modified: 2008-08-21 06:31 PDT (History)
10 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
two new script to generate the report (12.25 KB, application/x-gzip)
2003-02-13 10:17 PST, Rick Dean
no flags Details
screenshot of open count, priority vs. week (14.91 KB, text/html)
2003-02-13 10:21 PST, Rick Dean
no flags Details
screenshot of bug changes, priority-opens/closes/verifies vs. time (19.39 KB, text/html)
2003-02-13 10:24 PST, Rick Dean
no flags Details

Description Rick Dean 2003-02-13 10:12:21 PST
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.
Comment 1 Rick Dean 2003-02-13 10:17:09 PST
Created attachment 114351 [details]
two new script to generate the report

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.
Comment 2 Dave Miller [:justdave] (justdave@bugzilla.org) 2003-02-13 10:21:08 PST
-> Reporting/Charting
Comment 3 Rick Dean 2003-02-13 10:21:36 PST
Created attachment 114352 [details]
screenshot of open count, priority vs. week
Comment 4 Rick Dean 2003-02-13 10:24:09 PST
Created attachment 114353 [details]
screenshot of bug changes, priority-opens/closes/verifies vs. time
Comment 5 Gervase Markham [:gerv] 2003-02-14 16:26:16 PST
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
Comment 6 Joel Peshkin 2003-02-14 17:18:55 PST
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.

Comment 7 Gervase Markham [:gerv] 2003-02-15 14:41:37 PST
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
Comment 8 Joel Peshkin 2003-02-15 15:45:24 PST
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.
Comment 9 Gervase Markham [:gerv] 2003-02-16 01:18:11 PST
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
Comment 10 Mat 2004-03-17 03:00:07 PST
Any update folks....seems a dam cool feature to have in...
Comment 11 Joel Peshkin 2004-03-17 06:44:49 PST
Since I don't have the time to work on this and Gerv doesn't believe it should
be done, this needs a volunteer.
Comment 12 Wayne Mery (:wsmwk, NI for questions) 2005-08-21 07:43:01 PDT
(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.

Note You need to log in before you can comment on or make changes to this bug.