The Fedora blocker bug tracking app is a webapp which is designed to track the blocker ‘’link to page’’ and FE ‘’‘link to page’‘’ 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
- finish up dev docs
- start on production docs?
- figure out theme stuff - should it match fedora styling? how hard is it to do that with pdf? Is it needed?
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.
little bit of stuff about how the sync and cleanup algorithms work
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 not 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.