Fun with the BTS and an SQL DB
Hi, I have worked on importing the output of bugscan in a postgresql DB (on merkel.d.o). I am now able to run queries such as: * 10 maintainers with the highest number of bugs tagged patch (including * or excluding co-maintained packages) * bugs filed against packages no longer in Debian * total number of bugs opened in unstable, grouped by severity * ... (for details, the DB schema is readable on http://qa.debian.org/~lucas/pg-schema.sql ) The next step is to allow to record the evolution of the data. For example, I'd like to be able to graph the evolution of the number of open bugs in all the packages maintained or co-maintained by a given email address. For this, I'll probably run a daily cronjob that will run a query and store the result in a different table (I don't want to store all the information, but just a summary of it). Since I'll do a summary, I won't be able to regenerate the data if I want to get *more* information, so I have to determine carefully which summary to store. What I'm planning to do is to store on a daily basis: for all packages in Debian, for all packages maintained by the same person (restricting this to persons with at least 'n' bugs), for all packages maintained or co-maintained by the same person (restricting this to persons with at least 'n' bugs), for each package (restricting this to at least 'n' bugs), the number of packages in the group considered the number of open bugs in unstable for each severity the number of open bugs in unstable (excluding bugs tagged moreinfo or unreproducible) for each severity the number of open bugs in unstable not tagged moreinfo or unreproducible, but tagged patch, for each severity the number of release-critical bugs in testing *Can you think of other things that it would be interesting to store ?* (Of course, old rows will be removed after some time, using a simple expiration scheme) Thank you, -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Let's remove libapache-mod-gzip
reassign 401682 ftp.debian.org retitle 401682 RM: libapache-mod-gzip -- RoQA; Apache 1 only, orphaned thanks Hi all, Let's remove libapache-mod-gzip: - Supports Apache 1 only, which is about to be removed (see #418266). - Apache2 has this functionality built-in (mod_deflate). - Orphaned for 5 months with no takers. Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fun with the BTS and an SQL DB
On Fri, May 04, 2007 at 04:59:27PM +0200, Lucas Nussbaum wrote: > Hi, [...] > What I'm planning to do is to store on a daily basis: > for all packages in Debian, > for all packages maintained by the same person (restricting this to > persons with at least 'n' bugs), > for all packages maintained or co-maintained by the same person > (restricting this to persons with at least 'n' bugs), > for each package (restricting this to at least 'n' bugs), just out of curiosity: have you already thought how to size the threshold n ? great work btw :) filippo -- Filippo Giunchedi - http://esaurito.net PGP key: 0x6B79D401 random quote follows: Either this man is dead or my watch has stopped. -- Groucho Marx -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fun with the BTS and an SQL DB
On Fri, May 04, 2007 at 04:59:27PM +0200, Lucas Nussbaum wrote: > Hi, > > (for details, the DB schema is readable on > http://qa.debian.org/~lucas/pg-schema.sql ) just a few more comments on bugs_bugs: can it be useful to store usertags? what about added tags? I guess this would need to change the schema accordingly, and given that it doesn't happen very often it isn't a concern right now filippo -- Filippo Giunchedi - http://esaurito.net PGP key: 0x6B79D401 random quote follows: Frustra fit per plura, quod fieri potest per pauciora. It is vain to do with more what can be done with less. -- W. of Ockham -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFO: crystalspace, RC buggy > 1yr w/patch, not in oldstable/stable
crystalspace has been failing to build on alpha for > 1yr, even though a patch has been available in the BTS for 6 months today. Previous versions of the package built fine on all architectures, making this a serious regression and preventing the package's inclusion in a stable release (or in testing). Christian, are you still interested in maintaining this package, or should it be orphaned/removed from the archive (along with crystalspace-data)? If there's a reason the package should not be orphaned, I can do an NMU for bug #358044 (and 399843) as previously suggested (by someone who apparently wasn't a DD), but if the package isn't actually being maintained I'd rather not fix these bugs just to clear the way for an unmaintained package to enter testing. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFO: crystalspace, RC buggy > 1yr w/patch, not in oldstable/stable
On Fri, 2007-05-04 at 12:47 -0700, Steve Langasek wrote: > crystalspace has been failing to build on alpha for > 1yr, even though a > patch has been available in the BTS for 6 months today. Previous versions > of the package built fine on all architectures, making this a serious > regression and preventing the package's inclusion in a stable release (or in > testing). > > Christian, are you still interested in maintaining this package, or should > it be orphaned/removed from the archive (along with crystalspace-data)? > > If there's a reason the package should not be orphaned, I can do an NMU for > bug #358044 (and 399843) as previously suggested (by someone who apparently > wasn't a DD), but if the package isn't actually being maintained I'd rather > not fix these bugs just to clear the way for an unmaintained package to > enter testing. Hi Steve, If the package is orphaned, then I will consider to adopt it. So, if possible for you, no immediate removal please. If I adopt the package, then I intend to package a newer upstream release and see how the autobuilders deal with that, before studying the patches in the BTS. This approach has saved me some time before. :) Regards, Bart Martens signature.asc Description: This is a digitally signed message part
Re: Fun with the BTS and an SQL DB
On 04/05/07 at 18:24 +0200, Filippo Giunchedi wrote: > just out of curiosity: have you already thought how to size the > threshold n ? Not yet. The algorithm will probably be something like that: - get a list of interesting packages and maintainers - add the missing ones to the "permanent" list to monitor - for each entry in the "permanent" list of stuff to monitor, get the stats and store them. The idea is to avoid losing space to store uninteresting data. But don't forget that if 'n' = 10, but you maintain lots of packages with 10 (not higher than n) bugs, then *your* stats will still be recorded, but your packages' won't. On 04/05/07 at 18:32 +0200, Filippo Giunchedi wrote: > just a few more comments on bugs_bugs: > > can it be useful to store usertags? > > what about added tags? I guess this would need to change the schema > accordingly, > and given that it doesn't happen very often it isn't a concern right now Actually, adding/removing tags is easy. What I need to get right is which data I want to store over time. But the "snapshot" of the current BTS can evolve without breaking anything. usertags are stored in a separate DB (see merkel:/org/bugs.debian.org/spool/user/). It would be quite easy to add a different table to store them, but it would be a list of (user, usertag, bug) tuples. Since I don't see any interest in storing them as well, I'll leave that for later, but if you have a specific idea in mind, I can change that :-) Some quick results: n | packages with more than n bugs open in unstable 50 | 165 40 | 227 30 | 332 20 | 495 15 | 695 10 | 1043 5 | 1944 0 | 6783 n | Emails with more than n bugs open in unstable (excluding co-maintained packages) 100 | 121 50 | 269 25 | 421 20 | 494 15 | 601 10 | 751 5 | 996 n | Emails with more than n bugs open in unstable (INCLUDING co-maint) 25 | 650 20 | 726 15 | 848 10 | 1010 5 | 1261 So it would probably be reasonable to have n=20 for packages, and n=10 for maintainer and co-maintainer. Which would generate about 2300 rows per day. (and we can expire the old ones quite fast) -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
