Infrastructure/UpdateSystem

= Fedora Package Updating System [DRAFT] = Luke Macken 

Core

 * Core CVS -> Brew (Red Hat Internal build system) -> Fedora Update System (currently internal) -> Mirrors

Extras

 * Extras CVS -> Plague  ( Fedora Extras Buildsystem  ) -> Mirrors

Legacy

 * http://cvs.fedora.redhat.com/viewcvs/?root=legacy -> Plague ( Fedora Legacy Buildsystem )-> Mirrors

Next Generation Update System
These proposed changes will consolidate the package updating process for Core, Extras, and Legacy, allowing packages for any of the three trees to be updated using the same tool -- while still staying buildsystem independent. This infrastructure will aid in opening the Core package update process to the community as well.

Ideal Workflow
 Package updating   Building   Pending Update Stage   Submitted to Release Team   Pushing   Moving packages from Testing to Final (via dev intervention) 
 * Command line submission: make fedora-update
 * Web submission
 * CVS Integration? Allow dev edit specs, add/remove patches with ease, and commit/tag updates through a web interface.
 * xmlrpc submission to plague/brew for building.
 * somehow monitor when a build successfully completes and add it to the pending update queue.
 * Automatic QA of packages before they are submitted to the release team for signing/pushing
 * fedora-qa, rpmlint, rpmdiff, repoclosure, etc.
 * Release team signs package (until we get a signing server) and tells the updates system to 'Push'
 * Moves packages to proper fedora-stage
 * Header generation
 * Generate/insert extended update metadata
 * Sync to mirrors
 * Send update announcement mail
 * Move rpms to final stage directory
 * regenerate/reinsert metadata
 * Send update announcement mail