Workflow
The workflow in Fedora has changed drastically with the advent of F7 and the merged Core + Extras Repositories. For F8 and early F9 we need to work on streamlining the workflow so there is less that the maintainer has to do in a default case.
Goals
- In the default case, the maintainer should be able to work on a package all at one time and any additional steps for a successful package should be automatic (at least from the maintainer's point of view.)
- Overriding defaults should be possible from the commandline.
- As much as possible, the packager should be able to self-serve all the requirements of building their packages.
Package Update Workflow
Current
[Pull relevant information from here] http://fedoraproject.org/wiki/KevinFenzi/TypicalUpdateWorkFlow http://fedoraproject.org/wiki/JeremyKatz/DraftHowToUpdateYourFedoraPackage
Proposed
This proposal is a combination of a post by Ralf Corsepius and the thoughts of vairous people working on the new tools.
0. make changes to the pkg and checkin to the vcs 1. make tag build 1. If successful, package goes to a testing repo 2. otherwise, packager notified to look at build failure. STOP 2. Packager runs a command to submit information about this update. This should be filled in with default values if such values can be guessed. 1. Information could be submitted to Bodhi but Bodhi will have to be able to remember the values until the package becomes available. See 4.3.2 below. 3. Automated test suite run on package in testing repo 1. If successful, wait in the repo while humans test it 2. otherwise, package rejected and packager is notified of testing failure. STOP 4. Package leaves testing repo if one of these three things happen: 1. Timeout. After 1 week, the package automatically goes to the pending queue 2. Failed QA. Someone tests the package and finds problems STOP 1. This would likely be feedback from someone who uses the package followed by the maintainer pushing a button to reject the package. 3. Package approved early. 1. This would likely be up to the maintainer to list that the update should be pushed early and why. 2. The maintainer should be able to send this information along with the tag and the server can assign it to the package when the package leaves the buildsystem. 5. Package enters a push queue 6. Automated tests check the status of the repository if the packages in the queue were to be pushed (for instance, EVR and dep checks). 1. Success. Queue is sent to the update repository and the repodata is updated. STOP 2. Failed. Maintainer notified. releng has to recompose a manual push of a portion of the tree. STOP
Note: To make this automatic in the default case, there also needs to be a signing server involved at some point.
Some flowcharts from earlier design discussions: https://fedorahosted.org/bodhi/wiki/Design
Changes To Make this Happen
[Add me]
New Package Workflow
Current
[Add me]
Proposed
[Add me]
Changes to Make this Happen
[Add me]