Infrastructure/UpdatesSystem/IdealWorkflow

From FedoraProject

< Infrastructure | UpdatesSystem
Revision as of 22:27, 8 January 2010 by Akistler (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Contents

Ideal Workflow

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