From Fedora Project Wiki
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