Infrastructure/UpdatesSystem/IdealWorkflow

Update Submission (via web form/makefile target)

 * Make sure package is built and is being submitted for the release it is tagged for
 * Check for broken update paths
 * If not marked as a security issue, double check by scanning the severity/subject/group/etc of bugs, and the rpm changelog.

Pending Update Stage

 * Automatic QA of packages before they are submitted to the release team
 * fedora-qa, rpmlint, rpmdiff, repoclosure, etc.

Submitted to Release Team
(This entire step can be removed once either get a signing server or use detached gpg signatures from brew).
 * Release team signs package and tells the updates system to 'Push'.

Pushing

 * Moves packages to proper updates stage
 * Header generation via createrepo
 * Generate/insert extended update metadata into repo
 * Sync to mirrors
 * Comment/close associated bugs
 * Send update announcement mail
 * Send mail to developer

 Moving packages from Testing to Final  (Right now this step occurs when a developer chooses to 'Move update to Final'. Ideally, this system will provide an interface to allow testers to say whether a given testing update works or does not.  From here, we can automate moving updates to Final once they receive a number of positive ACKS, or after a given number of days in updates-testing (w/o negative feedback).)
 * Move rpms to final stage directory
 * regenerate/reinsert metadata
 * Send update announcement mail

Automated Periodic Jobs

 * updates repo cleaner
 * remove old packages
 * remove unnecessary metadata from the updateinfo.xml.gz
 * nagmail
 * fetching of archive update mail urls