Working on MattyT's Customised Resolutions branch, CUST_RES_BRANCH, I need to move charting into the DB so it works again. MattyT: could you please point me to documentation/bug comments about how Cust Res works? What tables it uses, etc. Gerv

Resolutions table. Should be self explanatory except restype which i doubt you need to bother with. You need to use IDs to handle renaming. I suggest you're interested in @::queryable_resolution from the versioncache for your resolution list. It would be really nice if resolution deletion didn't do the deletion of data for that resolution. I don't think it should. One implementation I was thinking is to maybe have a third 'zombie' state for the inactive field on resolutions. Resolutions stay here until the graphing data disappears for that resolution because it reaches the cutoff (is there one?) The more obvious alternative is to put a name for each resolution id somewhere.

Just a quick progress update. I have it importing legacy data, and I have the UI for choosing which charts to plot and plotting them. Next up is defining new charts. Gerv

OK, I am blocked on this bug by the query.cgi redesign - bug 98707. I can't do the UI for adding charts until that gets checked in, so I can modify it to allow chart addition. Doing the work on the current query.cgi would just mean a reimplementation, and doing it on the new one would make it hard to keep the patches disentangled. So, matty - review bug 98707 :-) Gerv

How is the chart bug selection stored in order to respect renaming, etc? Is anything being done to maintain the current nice feature where you can set up a chart condition that applies to all products, or do you have to manually add one for each product?

It doesn't appear that this is going to make it for 2.16, so we might start thinking about merging stored queries and charts. By this, I mean when you store a query you decide whether or not charting information gets recorded. To start with we could introduce a systemqueries table (bug #69000) in a similar way to the current personal stored queries table. Then we would have a column on systemqueries that indicated whether it is charted. A table would hang off it called systemcharting with the historical data. Allowing charting for personal stored queries would then be a future enhancement. System queries that are charted could never be user-relative (bug #41651).

We are currently trying to wrap up Bugzilla 2.16. We are now close enough to release time that anything that wasn't already ranked at P1 isn't going to make the cut. Thus this is being retargetted at 2.18. If you strongly disagree with this retargetting, please comment, however, be aware that we only have about 2 weeks left to review and test anything at this point, and we intend to devote this time to the remaining bugs that were designated as release blockers.

I didn't find the existance of collectstats.pl until around October. My company had already been using bugzilla for several months before that. With this refactoring a charting, will I be able to create charts that go all the way back to day 1 of our bugzilla installation? If not, should I create a new bug for this feature request?

Paul: See bug 80157

This will happen as part of 16009, which I am now actively working on. Consolidating. Gerv *** This bug has been marked as a duplicate of 16009 ***

clearing milestone on all DUPLICATE/WONTFIX/WORKSFORME/INVALID so they'll show up as untriaged if they get reopened. "Jiminy Cricket!" for the filters (and I don't care if it's spelled wrong ;)