[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#565219: qa.debian.org: bug history graphs are incorrect



On Thu, Jan 14, 2010 at 09:06:56AM +0100, Mike Hommey wrote:
> I've discussed this with both zack and don @debconf and the outcome is
> that it would be better if it were integrated within the BTS.
> 
> Now, as for the current graphs, I'm sorry to say that they just suck for
> several reasons:
> - The data they use is wrong. Take a look at the bug counts on ddpo and
>   the bug counts on the pts: they differ (look at iceweasel and iceape,
>   for instance). The pts is right, ddpo is wrong. Unfortunately, the
>   graphs use the ddpo data (which is the only one available to download
>   as a huge file with all information, afaik)
> - They occasionally break. Sometimes, bugs are not affected to the
>   correct package at bug report time, and that breaks the ddpo data
>   file. This is why we have files such as
>   http://people.debian.org/~glandium/bts/$/$.png
> - The RRD files were created with wrong parameters, which now induce a
>   lot of problems, such as if you change the priority of a bug, it will
>   end up being counted twice for at least a day.
> 
> I've been considering running a script on merkel to get the proper data
> instead of the ddpo one, but that would only solve part of the problem,
> and only for newer data. It would be nice to recreate the proper history
> from the BTS data, but that would be quite some work.
> Something else that would be nice to add to the graphs is the source
> uploads, and, possibly, a broader time span (but here again, the current
> rrd configuration doesn't permit).
> 
> I currently have some spare time, so I might get to work on some of
> these, but please feel free to give a hand.

FWIW, I switched to using the data from UDD today, so at least new bug
counts should be better (though the third problem above still remains).
I'm also experimenting new RRD settings on merkel. Graphs won't be
available there before tomorrow and won't contain any backlog.

Cheers,

Mike



Reply to: