Fedora Package Lifecycle notes

This is NOT official documentation
This page describes the packaging lifecycle from one person's own experience. Use the linked official documentation instead

Full Fedora package lifecycle

Do not get discouraged by the large number of steps and be patient: some of them depend only on you (the packager) and take little time, other steps are outside your control and can take a long time to complete.

Preparation

1. Check whether a package exists already 1
2. Check whether a review request exists already 2
3. Check whether the package would be allowed at all 35
4. Create bugzilla and FAS accounts, sign the CLA, upload your public SSH key, join the relevant mailing lists 6

Create the package

1. Familiarize yourself with the official guidelines 79
2. Create a .spec file following the official guidelines above
3. Make sure that your package builds (using rpmbuild or preferably mock)
4. Check that your package meets the review guidelines 11
5. Perform a Koji scratch build 12 (this requires having a FAS account, but doesn't require sponsoring)

Get the package reviewed 13

1. Upload your Spec file and SRPM to a public place (you can use your fedoraproject.org webspace if you are sponsored already 19)
2. Create a package review request 13, you will need the following info:
   • package name, short package description, full package description
   • Spec URL
   • SRPM URL
   • your FAS username
   • link to your Koji scratch build (optional)
   • if this is your first package block the FE-NEEDSPONSOR bug
3. fedora-review flag is blank, nobody is reviewing the package yet
4. be patient until you find a reviewer, they will set fedora-review flag to '?'
5. fix any issues, and be patient until the package is fully reviewed
6. when package is approved the flag will be set to '+'

Upload the package to rawhide

1. if this is your first package then find a sponsor and get sponsored into the packager group (you will get an email when this happens)
2. create a SCM admin request 15 by setting the fedora-cvs flag to '?' and using the exact template from the official documentation 15:
   • package name
   • short description
   • upstream URL
   • package owners (maintainer and co-maintainers)
   • branches: fedora and epel release branches
   • initialcc: FAS usernames receiving email regarding the package
3. about a day later an admin will set the fedora-cvs flag to '+'
4. at this point the repository should be created, and you can track the status at https://admin.fedoraproject.org/pkgdb/package/<yourpackage>
5. some time later the package will show up on https://apps.fedoraproject.org/packages/<yourpackage>
6. use fedpkg to import the package, push the changes and request a koji build for rawhide 16 Note: you are not allowed to force push your git branches, so take care to push working/tested commits, remembering to bump the spec revision each time and run rpmbuild/rpmlint before pushing
7. you can use 'koji download-build' to get the built package

Upload the package to Fedora release branches

1. read the update policy 17
2. once the Koji build succeeded and you've tested the package use fedpkg and merge master to your other branches, push your changes and request a koji build for each branch in turn
3. once the builds succeed and you've tested the package use 'fedpkg update' to request an update in Bodhi:
   • package name
   • type is newpackage
   • request is testing
   • bug number of your review request (bodhi can auto-close when package is stable)
   • notes: new package
   • auto-karma at default settings

1. your request will show up in bodhi as PENDING 18 https://admin.fedoraproject.org/updates/<package-name>
2. be patient, there might be an extra day or so delay when the package is being pushed
3. the package will go through the following states in bodhi 18
4. taskotron will run some automated tests on your package, giving it negative karma if it fails them
5. at some point it will start to get pushed "This update is currently being pushed to the Fedora N testing updates repository."
6. a (human) release engineer signs the PENDING updates and they get pushed to TESTING (on an almost daily basis?)
7. in TESTING fedora users can see your package if they have the updates-testing repository enabled in yum (default enabled for Alpha releases, disabled for final releases)
8. any fedora user with a FAS account can provide feedback (karma)
9. package gets promoted to stable if it receives enough positive karma, or enough time passes (3 days for alpha/beta and 7 days for released branches)

Upload the package to EPEL

TBD
where to get approval, what is the exact lifecycle for an EPEL package

1. [1]
2. EPEL packaging guidelines
3. EPEL Updates policy
4. EPEL incompatible upgrades policy

What is a package's status?

1. Search for package name on https://apps.fedoraproject.org/packages/ Found -> package is part of Fedora already
2. Open https://admin.fedoraproject.org/updates/<your-package-name> Found -> package has a Bodhi update request PENDING -> TESTING -> STABLE
3. Open https://apps.fedoraproject.org/packages/<your-package-name> Found -> package has (non-scratch) Koji builds
4. Open https://admin.fedoraproject.org/pkgdb/package/<your-package-name> Found -> package has SCM repo
5. Search on http://fedoraproject.org/PackageReviewStatus Found -> a package review request exists on bugzilla
6. Open https://bugzilla.redhat.com/show_bug.cgi?id=<review-bug-number> Look at flags on the right: fedora-review: - (blank): nobody is reviewing the package yet ? (assigned): the package is being reviewed, look for comments from reviewer + (approved): the package is approved by the reviewer fedora-cvs: not visible: you are not part of the packagers group, ask someone to sponsor you ? (scm-admin request): you (the packager) is requesting a git repo for your package + (scm repo created): admin created git repo
7. All of the above searches fail: there is no package (review) yet