Ticket #24 (assigned task)

Opened 4 years ago

Last modified 3 years ago

Post weekly summary of "most active bugs" to devel/testing lists

Reported by: kevin Owned by: josemm
Priority: major Milestone:
Severity: Simple Keywords:
Cc: till, hubbitus, robbieab Blocked By:
Blocking:

Description

A script needs to be run to post weekly to the devel/testing lists.

This script would talk to bugzilla and look for:

  • Most cc'ed bugs. What bugs have the most people cc'ed on them.
  • Bugs with the most comments in the last week. This would show bugs that are highly active.

is that possible to do with the xmlrpc interface?

See: http://meetbot.fedoraproject.org/fedora-meeting/2010-04-20/fesco.2010-04-20-19.00.log.html for more discussion.

Attachments

scraping-html.py (1.3 KB) - added by josemm 4 years ago.
Scarping html from report pages.
scraping-html.2.py (1.3 KB) - added by josemm 4 years ago.
Scarping html from report pages.
scraping-html-links.py (1.2 KB) - added by josemm 4 years ago.
Scraping html from report pages with links in output html
scrape-html-var.py (1.2 KB) - added by josemm 4 years ago.
Scraping html from report pages with links in output html and control variables

Change History

comment:1 Changed 4 years ago by mmcgrath

  • Owner set to josemm

Assigning to josemm

comment:2 Changed 4 years ago by josemm

  • Status changed from new to assigned

This cannot be done via the XMLRPC interface. I have been through the bugzilla xmlrpc documentation and confirmed it.

~Jose

comment:4 Changed 4 years ago by kevin

That seems very messy, but not sure how else to do this. ;(

comment:5 Changed 4 years ago by josemm

I have written a test script which searches the bugs with comments above 100 and cced people greater than 100, it limits the number of bugs to 50 since there are too many to process quickly. The code should print an output html file output-<version>.html eg: output-12.html

Changed 4 years ago by josemm

Scarping html from report pages.

Changed 4 years ago by josemm

Scarping html from report pages.

comment:6 Changed 4 years ago by josemm

updated with last week and reduced number of comments and cced to 5.

comment:8 Changed 4 years ago by kevin

Cool. :)

So are these sorted by most activity?

Also, would it be possible to make the generated output use links/etc so you could easily click on them?

The rawhide output looks odd. Bunch of new review requests... I guess due to the number of cc's added for review requests?

comment:9 Changed 4 years ago by josemm

a). They are sorted according to the selection criteria mentioned in the ticket(Most Cced and Most comments) b). I actually had the links removed to make it look cleaner. c). Yes this is because of the number of cced people on the review requests.

~ Jose

Changed 4 years ago by josemm

Scraping html from report pages with links in output html

comment:10 Changed 4 years ago by kevin

Thanks for the work on this. ;)

Looking at it, I think we may need to tune things a bit... right now all the rawhide ones are FTBFS. I tried changing the '5' limit here to 10 or 15, but it didn't seem to change the output any. ;( Does bugzilla just ignore that if there are no bugs with 10 or 15 cc's?

Or did I not change the query in the right place?

Can we see what 10 cc's and 10 comments looks like? Should be a much smaller list?

comment:11 Changed 4 years ago by josemm

No I think its that the query was not changed in the correct places. thought I would make it easier for you, so I have added in two variables comments and cced. They will change the corresponding values in the query. :)

check scrape-html-var.py

~Jose

Changed 4 years ago by josemm

Scraping html from report pages with links in output html and control variables

comment:12 Changed 4 years ago by kevin

odd. So, running that I see in the rawhide report the first bug is:

600037 high high Linux Adam Goode NEW FTBFS nip2-7.20.7-4.fc14

It has 1 cc person and 6 comments. Shouldn't it not match this search for 10 and 10?

comment:13 Changed 4 years ago by josemm

The query might be wrong... Will fix that..

comment:14 Changed 4 years ago by josemm

Looks like we have a problem... the cc field can only be string based. the results currently being returned are because the search criterion is being ignored. :(

comment:15 Changed 4 years ago by kevin

Ugh. :(

Could any of the standard bugzilla reports help us here?

comment:16 Changed 4 years ago by josemm

I guess I have found an answer for our dilemma.

The xmlrpc has this option in the search query.

"last_change_time

dateTime Searches for bugs that were modified at this time or later. May not be an array."

Can this be used as an equivalent to one of the above criteria?

comment:17 Changed 4 years ago by till

  • Cc till added

I filed a bugzilla feature request: https://bugzilla.redhat.com/show_bug.cgi?id=626613

Also I noticed that "Time since Assignee touched" might allow to perform an interesting query.

comment:18 Changed 4 years ago by hubbitus

  • Cc hubbitus added

comment:19 Changed 4 years ago by josemm

Current Status: The ticket is on bugzilla as a feature request, no replies yet... Will keep exploring other options.

comment:20 Changed 3 years ago by kevin

Any other thoughts on how to approach this?

We have all our bugs cc'ing extras-qa@…, I wonder if we could do some kind of processing of those bugzilla emails and do a report weekly on them?

comment:21 Changed 3 years ago by johannbg

Any particular reason we want to stick with high cc and comments count than just get a daily feedback of *all* reported bugs?

I'm a bit worried we might miss *import* bugs for the *popular* ones...

comment:22 Changed 3 years ago by johannbg

s/import/important

comment:23 Changed 3 years ago by kevin

Well, a daily report of ALL fedora bugs changed might be a bit on the massive/information overload side.

If I do a search for all fedora bugs changed in one day for monday->tuesday, I get 642 bugs. ;(

Anyhow, ideas welcome for a stripped down list that we could use to allocate more resources to fix.

comment:24 Changed 3 years ago by robbieab

How about a count of bugs generating most emails in a given time frame? Would that provide enough information?

comment:25 Changed 3 years ago by josemm

Good idea will look into the api and the idea over the weekend and report back by Sunday :)

~Jose

comment:26 Changed 3 years ago by robbieab

  • Cc robbieab added

Thanks Jose.

I know it's a bit of a round about way, but if they are looking to measure "bug heat", it might work.

Note: See TracTickets for help on using tickets.