97760 - Management reports in Bugzilla

Status: NEW

(Bugzilla :: Reporting/Charting, enhancement, P3)

Description

[Lukas Gruetzmacher]

I've tried to create a new chart line wich shows the avaranged number of days 
need to resove a bug.
My changes are very simple and may not be work for all situation.
But it's a begin.

Please view the patch (see attachments) and send me comments.

Comment 1

[Lukas Gruetzmacher]

Attachment: simple patch on collectstats.pl

Comment 2

[Lukas Gruetzmacher]

The current version of my change has still a problem: If a product has no 
changes in the last 30 days the scripts prompts an error and I see only the 
additional '|' in the data file.
Maybe you can solve this problem, I couldn't.

Comment 3

[Dave Miller [:justdave]]

moving to Bugzilla

Comment 4

[Dave Miller [:justdave]]

Comment on attachment 47794 [details] [diff] [review]
simple patch on collectstats.pl

per the submitter's comments, marking the patch as "needs work"

Comment 5

[Paul Baker]

I like this idea, this would be a very interesting statistic to have indeed!

Comment 6

[Gervase Markham [:gerv]]

I am assigning all the bugs I am not working on in the immediate future to
[e-mail]. This means:

- I will be able to search for bugs assigned to me as a list of bugs I'm going
to fix (which is as it should be), and
- people won't falsely assume I might be about to fix a bug when I'm not.

Gerv

Comment 7

[Mat]

Any update on this ? I for one would like this feature....management want to be
able to track issue resolution time...

Comment 8

[Gervase Markham [:gerv]]

As it says, nobody's working on it...

Gerv

Comment 9

[Dave Miller [:justdave]]

Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004.  Anything flagged
enhancement that hasn't already landed is being pushed out.  If this bug is
otherwise ready to land, we'll handle it on a case-by-case basis, please set the
blocking2.20 flag to '?' if you think it qualifies.

Comment 10

[Kevin Benton]

This looks like a job for statuscount.cgi!  :)

Comment 11

[Kevin Benton]

I'm taking this a different direction as statuscount.cgi doesn't use
collectstats.pl results at all.  It gathers the information from the DB live.

Comment 12

[Kevin Benton]

I expect the first release of this software to come up after the code freeze is
released.

Comment 13

[ash]

how's this going?  my employer would be very happy if a time to resolution
report were available.  we might possibly have resources to devote to this at
some point if that's the only way to get it.

Comment 14

[Kevin Benton]

Since you asked, the current reports are as follows:

Bug Aging (0-7, 7-14, 14-30, 30-90, 90+ days)
Change Control Board
Current Bug Status
Formerly Closed Bugs
Never Changed Bugs
Status Change Graphs
Product Status Change Graphs
Component Status Change Graphs
Assigned-To Status Change Graphs
Status Changes
Time To Closure
Time To Resolution

These reports may be limited by Product, Product/Component, Changed By,
Assigned-To, or Date Range.

Comment 15

[Frédéric Buclin]

The trunk is now frozen to prepare Bugzilla 2.22. Enhancement bugs are retargetted to 2.24.

Comment 16

[Kevin Benton]

Expect update to this bug within the next two months.  Finishing up changes.

Comment 17

[Douglas Calvert]

bug 289898 seems somewhat related 

Kevin, I am very interested in free-riding on your work for this bug:) How are you coming along? 

Comment 18

[Frédéric Buclin]

This bug is retargetted to Bugzilla 3.2 for one of the following reasons:

- it has no assignee (except the default one)
- we don't expect someone to fix it in the next two weeks (i.e. before we freeze the trunk to prepare Bugzilla 3.0 RC1)
- it's not a blocker

If you are working on this bug and you think you will be able to submit a patch in the next two weeks, retarget this bug to 3.0.

If this bug is something you would like to see implemented in 3.0 but you are not a developer or you don't think you will be able to fix this bug yourself in the next two weeks, please *do not* retarget this bug.

If you think this bug should absolutely be fixed before we release 3.0, either ask on IRC or use the "blocking3.0 flag".

Comment 19

[Kevin Benton]

Attachment: Some interesting code - some works, some doesn't, but it's definitely worth study for others.

This code is not completely functional though it provides a basis for further work.

Comment 20

[Kevin Benton]

Attachment: Some interesting code - some works, some doesn't, but it's definitely worth study for others.

This code is not completely functional though it provides a basis for further work.

Comment 21

[Joel Peshkin]

A few notes for the TODO list for whoever wants to drive this forward....

1) When this gets done, it should certainly query against the shadow database rather than the primary.  Also, this is the type of reporting where you will get a huge performance advantage out of preparing the query using placeholders and caching and reusing the sth.

2) Bug aging seems like a place where we should be trying out views in the databases.  It also seems like finding a transition in bugs_activity could be done by LEFT JOIN-ing a bug list to bugs_activity ON bug_id AND field_id AND added/removed and then selecting the earliest/latest so the most useful indices may well not be a fulltext but (bug_id, field_id, added, bug_when) and (bug_id, field_id, removed, bug_when)

3) Using the JOIN-ing approach, it is probably possible to create derived columns that Search.pm knows about that let any query have a "column" for bug_age, time_from_open_to_last_resolve_or_now_if_still_open, etc....   If we do that in Search.pm, then all of our charting functions will know how to do this.  We just have to give some real thought about how to do this without making the Search user interface any worse.

Comment 22

[Kevin Benton]

FYI all - I haven't looked at the code I attached above in over a year so I know that it needs a lot of improvements, but as I stated above, it's provided as a basis for continuing work.  Joel makes a lot of good comments.  Joel - if you'd like to pick up where I left off, feel free. :)

Comment 23

[Kevin Benton]

I am unable to work this bug at this time due to other priorities.  Reassigning to default assignee.

Comment 24

[Max Kanat-Alexander]

Bugzilla 3.2 is now frozen. Only enhancements blocking 3.2 or specifically approved for 3.2 may be checked in to the 3.2 branch. If you would like to nominate your enhancement for Bugzilla 3.2, set the "blocking3.2" flag to "?", and either the target milestone will be changed back, or the blocking3.2 flag will be granted, if we will accept this enhancement for Bugzilla 3.2.

Comment 25

[Frédéric Buclin]

We are going to branch for Bugzilla 4.4 next week and this bug is either too invasive to be accepted for 4.4 at this point or shows no recent activity. The target milestone is reset and will be set again *only* when a patch is attached and approved.

I ask the assignee to reassign the bug to the default assignee if you don't plan to work on this bug in the near future, to make it clearer which bugs should be fixed by someone else.