Infrastructure/UpdatesSystem/IdealWorkflow

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