The Fedora blocker bug tracking app is a webapp which is designed to track the blocker and Freeze Exception bugs throughout the blocker process during a release.
While this data is currently stored in bugzilla, the queries needed to retrieve affected bugs can be complicated and very and the information which determines the current blocker status of a bug is not always intuitive. This application was developed as an in-between interface between users and bugzilla so that there is an easily scannable interface for determining blocker status.
The documentation here is a quicker overview on how the application is architected some of the tools used in addtion to build instructions.
- remember how to link between pages
- rewrite dev docs
- write section on production deployment
- reorganize the info on the index - should deps be in a different page?
- figure out theme stuff - should it match fedora styling? how hard is it to do that with pdf? Is it needed?
- write docs for configuration options
- write readme pointing to conventions etc.
This project started its life as a script to update a wiki page for a easily scannable record of the current bugs in the blocker/fe process. When that script was broken after a bugzilla API update, it was supposed to be rewritten to generate static HTML instead of updating a wiki page.
Through the initial development process, the feature set started getting beyond what could reasonably be done with a staic site generator and the current application was born.
While still on the simple side for a dynamic webapp, the stage is set for much more functionality and has proven to be quite useful during the inital release (Fedora 18).
The application is designed for two interfaces to the data; the web based front end and a backend daemon responsible for keeping locally cached data up to date with the original data in bugzilla.
At this point, the data cache is read-only from the web frontend, making potential conflicts between bugzilla, bodhi and the cache much less likely.
The main data sources used to determine status are bugzilla for bug status information and bodhi for update status information.
The synchronization algorithms for bugzilla is designed to pull information from bugzilla only when it needs to unless a full sync is requested. The query has several terms which limit the bugs identified based on modification time. To be specific, other than blocking the appropriate tracker, creation in the last day or any changes in the following bug attributes will cause it to be identified by the query
- blocks
- status
- dependson
- summary
- component
Prior to every synchronization run, bugs which are closed or no longer block the trackers are marked as inactive and ignored for the purposes of display or farther synchronization.
Synchronization with bodhi is not quite as complicated due to some limitations in bodhi’s API at the time the code was written. For every active bug in a milestone, the algorithm checks to see if there are any updates marked as fixing that bug. If an update does exist, data is extracted and added to the local database.
It seems like there are about a million choices for css and javascript frameworks anymore and they all have their advantages and disadvantages.
The blocker tracking app uses sass and compass to generate the css used by the actual webapp. Zurb Foundation is used as a base css framework.
Note that while compiled css does exist in the source directory, it should ‘’never’’ be edited by hand - all CSS changes should be done in the SASS source and re-compiled to regular CSS before checking in. Any manual changes to CSS run the risk of being overwritten at a later date.
There isn’t a lot of javascript used in this application but the little which is used does provide important functionality
Tablesorter is used in the bug tables to enable client-side sorting of the tables without server interaction.