Interactive sorting of reports/problems

[owtaylor]

I've been using FAF on retrace.fedoraproject.org to sort out crashes in GNOME Shell. I found that it was cumbersome because there was no way to accumulate information - to mark that two problems were the same, to give a more useful name for a problem with a generic "crash function" like g_log, to mark down the GNOME BZ #, to indicate that the problem had a fix in GNOME git, or simply to make notes on the problem.

I first tried writing down information in a text file, but I found that frustrating because after sorting through all the bugs for a week, there was no way to update it to the next week other than starting over.

So what I did was create a litle web app that read from two sources - JSON queries against retrace.fedoraproject.org and a lookaside spreadsheet in Google sheets, and then combined them into a report:

• Result: http://crash-sort.fishsoup.net
• Lookaside: https://docs.google.com/spreadsheets/d/1OgrkFOookACskxT6EXkWZ3ajPWZxXgStr7sQnOqjdOw/edit?usp=sharing
• Code: http://git.fishsoup.net/cgit/crash-sort/

Queries against FAF are cached to speed up the cycle time of editing the lookaside document and reloading (and to reduce any load on retrace.fedoraproject.org.) The items in the report correspond either to a) rows in the lookaside document that might include multiple problems b) unmatched problems.

The experience here works wellfor my needs, but it would be even better if FAF can be improved to provide something equivalent without needing a layer on top.

One approach would be to do something pretty literally like what I did and introduce another object into FAF that is tied manually to one or more reports and allows commenting, marking the status, etc. However, that makes the overall model rather complex and hard to understand. (What do you even call these things? In the crash-sort code these are "crashes", but I don't think that's very descriptive.)

The other approach would be to work off of associated bugs - this doesn't work that well now, for various reasons:

• Bug data updates are very slow - there's no ability to make changes to bugs and have that be reflected instantly. (I'm not sure what the latency is for bug data updates - a day?)
• Duplicates aren't followed, so a problem shows as "CLOSED" if the bugzilla bug associated with a report is duplicated, instead of the actual status of the bug that it has been duplicated to.
• There is no aggregation, so if the same bugzilla bug shows up as multiple problems, they aren't combined when searching for problems
• Problems are listed only by crash function, while the bugzilla bug title might be more informative

I think these are all fixable, though with non-trivial technical work. My understanding is that some time in the next 3-4 months a feed from bugzilla.redhat.com to fedmsg will go live, and that presumably could be used to make bug data near-time correct. Following duplicates and aggregating based on the de-duplicated bugs probably requires moving more of the logic from the database to the frontend, probably with some extra caching.

I wanted to file this to see if there is interest in trying to accomodate this use of FAF for interactive sorting, and what approach people might think would work well.

[sorki]

Thank you for you extensive analysis - I'm definitely interested in efforts to make Faf more useful.

Your feedback is really valuable as while we build the tools we don't actually know that much about how people actually use them so we can just guess and try to invent workflows that might fit the actual use cases.

Live feed from bugzilla will indeed make bug syncing faster and much easier for us.