.. Fedora Blocker Bug Tracker documentation master file, created by
   sphinx-quickstart on Thu Jan 17 14:06:23 2013.
   You can adapt this file completely to your liking, but it should at least
   contain the root `toctree` directive.

Welcome to Fedora Blocker Bug Tracker's documentation!
======================================================

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.

TODO
----
  * 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?
Introduction
------------

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).

Basic Architecture
------------------

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 things that we're interested in tracking are:
   * blocker status
   * bug information
   * updates which should fix the bug in question

Data Sources
____________

The main data sources used to determine status are `bugzilla`_ for bug status
information and `bodhi`_ for update status information.

syncronization
______________

little bit of stuff about how the sync and cleanup algorithms work

html
----

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.


js
__

There isn't a lot of javascript used in this application but the little which is
used does provide important functionality

Sortable Tables
***************
tablesorter

Tooltips
********
tooltip library

.. _bugzilla: https://bugzilla.redhat.com/
.. _bodhi: https://admin.fedoraproject.org/updates/

.. toctree::
   :maxdepth: 2

   development
   installation

Indices and tables
==================

* :ref:`genindex`
* :ref:`modindex`
* :ref:`search`