193177 - new report print bug counts and changes vs. time

Status: NEW

(Bugzilla :: Reporting/Charting, enhancement)

Description

[Rick Dean]

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]

Attachment: 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]]

-> Reporting/Charting

Comment 3

[Rick Dean]

Attachment: screenshot of open count, priority vs. week

Comment 4

[Rick Dean]

Attachment: screenshot of bug changes, priority-opens/closes/verifies vs. time

Comment 5

[Gervase Markham [:gerv]]

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]

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]]

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]

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]]

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]

Any update folks....seems a dam cool feature to have in...

Comment 11

[Joel Peshkin]

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)]

(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.