From Fedora Project Wiki

Latest revision as of 22:19, 20 March 2015

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

Fedora package lifecycle

A package goes through the following states from its creation until its part of a release. At each state you can take the listed steps to move it to the next state.

Unknown
- This procedure tries to find out where in its lifecycle a package is by searching for lifecycle states in reverse order:
- Check whether a package exists already in a release ^[1]
- Check whether the package has (non-scratch) Koji builds https://apps.fedoraproject.org/packages/<your-package-name>
- Check whether a SCM repository exists already https://admin.fedoraproject.org/pkgdb/package/<your-package-name>
- Check whether a review request exists already ^[2]
- Check whether the package would be allowed at all ^[3] ^[4]
Not found
- You can become a package maintainer and create a package yourself
- Familiarize yourself with the official guidelines ^[5] ^[6]
- Create a .spec file following the official guidelines above
- Make sure that your package builds (using rpmbuild or preferably mock ^[7])
- Check that your package meets the review guidelines ^[8]
- (optional) perform a Koji scratch build ^[9] (this requires having a FAS account, but doesn't require sponsoring)
- (optional) run fedora-review to get prepared for the review. The output doesn't have to be perfect, certain things may be safe to ignore. Discuss with your reviewer/sponsor if you are uncertain on what to do with the warnings reported.
Creating review request
- Upload your spec and SRPM files to a public place (you can use your fedoraproject.org webspage if you are sponsored already ^[10], or some personal site otherwise)
- Create a package review request ^[11]. You'll need to have the following information at hand:
  - 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
Review requested: fedora-review is -
- nobody is reviewing the package yet
- be patient until you find a reviewer, they will set the fedora-review flag to ?
Under review: fedora-review is ?
- a fedora packager is reviewing your package, be patient and solve any issues they find.
- Increment the spec release version, add a changelog entry, and post the new spec, SRPM and (optionally) Koji URLs to bugzilla together with an explanation of what you changed.
- iterate until the reviewer approves your package, at which point they will set the fedora-review flag to +
Approved: fedora-review is +
- if this is your first package then find a sponsor, see becoming a packager
- create a SCM admin request ^[12] by setting the fedora-cvs flag to ? and using the exact template from the official documentation ^[13]. You will need the following information at hand:
  - package name
  - short description
  - upstream URL
  - package owners (maintainer and co-maintainers)
  - branches: fedora and epel release branches that you want to target
  - list of FAS usernames receiving email regarding the package (probably just you unless package is co-maintained)
SCM repository requested: fedora-cvs flag is ?
- wait for about a day, when an admin will set the fedora-cvs flag to +
SCM repository granted: fedora-cvs flag is +
- at this point the repository should be created, and you can track the status at https://admin.fedoraproject.org/pkgdb/package/<your-package-name>
- might take about an hour until your permissions are synchronized
- use fedpkg to import the package, and push the changes^[14]
- Test your commits: you are not allowed to force push your git branches, so take care at least run fedpkg local and fedpkg lint to check for problems before pushing any changes. Remember to bump the spec revision and add a changelog entry in the spec file each time
- request a koji build for rawhide from your master branch with fedpkg build: koji will build for x86_64, i686 and armv7l.
- You can access the build logs from the koji webinterface or cli.
- you can use koji download-build to get the built package
- some time later the package will show up on https://apps.fedoraproject.org/packages/<your-package-name>
Has koji build for rawhide
- make sure to always request a build for rawhide (master branch) before pushing or requesting builds for other branches
- read the update policy ^[15]
- 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
Has koji build for a (branched) fedora release
- once the builds succeed and you've tested the package use 'fedpkg update' to request an update in Bodhi. You will need the following information:
  - 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
- bodhi (?) will also trigger a build for s390 and s390x
- your request will show up in bodhi as PENDING ^[16]https://admin.fedoraproject.org/updates/<package-name>
Bodhi shows PENDING status for package
- the package goes through PENDING -> TESTING -> STABLE for each fedora release independently. Note that rawhide builds must not be submitted to Bodhi, they should be available automatically after some time.
- while in this state users cannot yum install or dnf install your package yet
- a (human) release engineer manually signs and pushes packages from PENDING to TESTING almost daily
- be patient, there might be an extra day or so delay when the package is being pushed
- taskotron will run some automated tests on your package, posts its logs to bodhi and gives negative karma if it fails any tests
- at some point it will start to get pushed "This update is currently being pushed to the Fedora N testing updates repository."
Bodhi shows TESTING status for package
- in TESTING fedora users can see your package if they have the updates-testing repository enabled in yum or dnf (default enabled for Alpha releases, disabled for final releases): yum install --enablerepo="*-testing" <your-package-name> or dnf install --enablerepo="*-testing" <your-package-name>
- any fedora user with a FAS account can provide feedback (karma)
- 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)
- it can also get rejected if it receives too much negative karma, at which point you have the fix the problems and submit a new spec revision that will become PENDING again
Bodhi shows STABLE status for package
- users can now install your package as usual with yum install <yourpackage> or dnf install <yourpackage>

EPEL package lifecycle

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

- Read the EPEL policies ^[17] ^[18] ^[19] ^[20]

New packager

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.
Create a bugzilla account ^[21]
Create a FAS account ^[22]
Login to FAS and sign the CLA, upload your public SSH key, and (optionally) your OpenPGP key
Consult the documentation ^[23]
At this point you can submit your package review request
- Make sure to block the FE-NEEDSPONSOR bug if you are not yet sponsored into the packager group (i.e. this is your first package)
Inform upstream that you are packaging their software
Join the relevant mailing lists ^[24] ^[25]
Send a self-introduction email ^[26]
Respond to bugzilla comments until your package is approved
Get sponsored into the packager group (you will get an email when this is done) ^[27] ^[28]
Read the package maintenance guide and upload your package ^[29]
Submit your package to (branched) releases using Bodhi

References

Retrieved from "https://fedoraproject.org/w/index.php?title=Fedora_Package_Lifecycle_notes&oldid=407154"

@@ Line 1: / Line 1: @@
 {{admon/caution|This is NOT official documentation|This page describes the packaging lifecycle from one person's own experience.
-Use the linked official documentation instead}}
+Use the [[#References|official documentation]] instead}}
-= Full Fedora package lifecycle =
+= Fedora package lifecycle =
-Do not get discouraged by the large number of steps and be patient: some of them depend only on
+A package goes through the following states from its creation until its part of a release.
-you (the packager) and take little time, other steps are outside your control
+At each state you can take the listed steps to move it to the next state.
-and can take a long time to complete.
-== Preparation ==
+# Unknown
+#* This procedure tries to find out where in its lifecycle a package is by searching for lifecycle states in reverse order:
+#* Check whether a package exists already in a release <ref>https://apps.fedoraproject.org/packages/</ref>
+#* Check whether the package has (non-scratch) Koji builds <code>https://apps.fedoraproject.org/packages/<your-package-name></code>
+#* Check whether a SCM repository exists already <code>https://admin.fedoraproject.org/pkgdb/package/<your-package-name></code>
+#* Check whether a review request exists already <ref>http://fedoraproject.org/PackageReviewStatus/</ref>
+#* Check whether the package would be allowed at all <ref>http://fedoraproject.org/wiki/Forbidden_items</ref> <ref>http://fedoraproject.org/wiki/Packaging:LicensingGuidelines</ref>
+# Not found
+#* You can [[#NewPackager|become a package maintainer]] and create a package yourself
+#* Familiarize yourself with the official guidelines <ref>http://fedoraproject.org/wiki/Packaging:Guidelines</ref> <ref>http://fedoraproject.org/wiki/Packaging:OCaml</ref>
+#* Create a .spec file following the official guidelines above
+#* Make sure that your package builds (using rpmbuild or preferably mock <ref>http://fedoraproject.org/wiki/Using_Mock_to_test_package_builds</ref>)
+#* Check that your package meets the review guidelines <ref>http://fedoraproject.org/wiki/Packaging:ReviewGuidelines</ref>
+#* (optional) perform a Koji scratch build <ref>http://fedoraproject.org/wiki/Package_Review_Process#Contributor</ref> (this requires having a FAS account, but doesn't require sponsoring)
+#* (optional) run <code>fedora-review</code> to get prepared for the review. The output doesn't have to be perfect, certain things may be safe to ignore.  Discuss with your reviewer/sponsor if you are uncertain on what to do with the warnings reported.
+# Creating review request
+#* Upload your <code>spec</code> and <code>SRPM</code> files to a public place (you can use your fedoraproject.org webspage if you are sponsored already <ref>https://fedoraproject.org/wiki/Infrastructure/fedorapeople.org</ref>, or some personal site otherwise)
+#* Create a package review request <ref>https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora&format=fedora-review</ref>. You'll need to have the following information at hand:
+#** 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
+# Review requested: '''fedora-review''' is '''-'''
+#* nobody is reviewing the package yet
+#* be patient until you find a reviewer, they will set the '''fedora-review''' flag to '''?'''
+# Under review: '''fedora-review''' is '''?'''
+#* a fedora packager is reviewing your package, be patient and solve any issues they find.
+#* Increment the spec release version, add a changelog entry, and post the new <code>spec</code>, <code>SRPM</code> and (optionally) Koji URLs to bugzilla together with an explanation of what you changed.
+#* iterate until the reviewer approves your package, at which point they will set the <code>fedora-review</code> flag to '''+'''
+# Approved: '''fedora-review''' is '''+'''
+#* if this is your first package then find a sponsor, see [[#NewMaintainer|becoming a packager]]
+#* create a SCM admin request <ref>http://fedoraproject.org/wiki/Package_SCM_admin_requests</ref> by setting the '''fedora-cvs''' flag to '''?''' and using the exact template from the official documentation <ref>http://fedoraproject.org/wiki/Package_SCM_admin_requests</ref>. You will need the following information at hand:
+#** package name
+#** short description
+#** upstream URL
+#** package owners (maintainer and co-maintainers)
+#** branches: fedora and epel release branches that you want to target
+#** list of FAS usernames receiving email regarding the package (probably just you unless package is co-maintained)
+# SCM repository requested: '''fedora-cvs''' flag is '''?'''
+#* wait for about a day, when an admin will set the '''fedora-cvs''' flag to '''+'''
+# SCM repository granted: '''fedora-cvs''' flag is '''+'''
+#* at this point the repository should be created, and you can track the status at <code>https://admin.fedoraproject.org/pkgdb/package/<your-package-name></code>
+#* might take about an hour until your permissions are synchronized
+#* use {{package|fedpkg}} to import the package, and push the changes<ref>http://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Get_Sponsored</ref>
+#* Test your commits: you are not allowed to force push your git branches, so take care at least run <code>fedpkg local</code> and <code>fedpkg lint</code> to check for problems before pushing any changes. Remember to bump the spec revision and add a changelog entry in the spec file each time
+#* request a koji build for rawhide from your master branch with <code>fedpkg build</code>: koji will build for <code>x86_64</code>, <code>i686</code> and <code>armv7l</code>.
+#* You can access the build logs from the koji webinterface or cli.
+#* you can use <code>koji download-build</code> to get the built package
+#* some time later the package will show up on <code>https://apps.fedoraproject.org/packages/<your-package-name></code>
+# Has <code>koji</code> build for rawhide
+#* make sure to always request a build for rawhide (master branch) before pushing or requesting builds for other branches
+#* read the update policy <ref>http://fedoraproject.org/wiki/Updates_Policy</ref>
+#* 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
+# Has <code>koji</code> build for a (branched) fedora release
+#* once the builds succeed and you've tested the package use 'fedpkg update' to request an update in Bodhi. You will need the following information:
+#** 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
+#* bodhi (?) will also trigger a build for <code>s390</code> and <code>s390x</code>
+#* your request will show up in bodhi as PENDING <ref>https://fedoraproject.org/wiki/Bodhi#Pending</ref><code>https://admin.fedoraproject.org/updates/<package-name></code>
+# Bodhi shows PENDING status for package
+#* the package goes through PENDING -> TESTING -> STABLE for each fedora release independently. Note that rawhide builds must not be submitted to Bodhi, they should be available automatically after some time.
+#* while in this state users cannot <code>yum install</code> or <code>dnf install</code> your package yet
+#* a (human) release engineer manually signs and pushes packages from PENDING to TESTING almost daily
+#* be patient, there might be an extra day or so delay when the package is being pushed
+#* taskotron will run some automated tests on your package, posts its logs to bodhi and gives negative karma if it fails any tests
+#* at some point it will start to get pushed &quot;This update is currently being pushed to the Fedora N testing updates repository.&quot;
+# Bodhi shows TESTING status for package
+#* in TESTING fedora users can see your package if they have the <code>updates-testing</code> repository enabled in {{package|yum}} or {{package|dnf}} (default enabled for Alpha releases, disabled for final releases): <code>yum install --enablerepo="*-testing" <your-package-name></code> or <code>dnf install --enablerepo="*-testing" <your-package-name></code>
+#* any fedora user with a FAS account can provide feedback (karma)
+#* 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)
+#* it can also get rejected if it receives too much negative karma, at which point you have the fix the problems and submit a new spec revision that will become PENDING again
+# Bodhi shows STABLE status for package
+#* users can now install your package as usual with <code>yum install <yourpackage></code> or <code>dnf install <yourpackage></code>
-# Check whether a package exists already [https://apps.fedoraproject.org/packages/ 1]
+= EPEL package lifecycle =
-# Check whether a review request exists already [http://fedoraproject.org/PackageReviewStatus/ 2]
+{{admon/warning|TBD|where to get approval, what is the exact lifecycle for an EPEL package}}
-# Check whether the package would be allowed at all [http://fedoraproject.org/wiki/Forbidden_items 3][http://fedoraproject.org/wiki/Packaging:LicensingGuidelines 5]
-# Create bugzilla and FAS accounts, sign the CLA, upload your public SSH key, join the relevant mailing lists [http://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Becoming_a_Fedora_Package_Collection_Maintainer 6]
-== Create the package ==
-# Familiarize yourself with the official guidelines [http://fedoraproject.org/wiki/Packaging:Guidelines 7][http://fedoraproject.org/wiki/Packaging:OCaml 9]
-# Create a .spec file following the official guidelines above
-# Make sure that your package builds (using rpmbuild or preferably mock)
-# Check that your package meets the review guidelines [http://fedoraproject.org/wiki/Packaging:ReviewGuidelines 11]
-# Perform a Koji scratch build [http://fedoraproject.org/wiki/Package_Review_Process#Contributor 12] (this requires having a FAS account, but doesn't require sponsoring)
-== Get the package reviewed [https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora&format=fedora-review 13] ==
-# Upload your Spec file and SRPM to a public place (you can use your fedoraproject.org webspace if you are sponsored already [https://fedoraproject.org/wiki/Infrastructure/fedorapeople.org 19])
+#* Read the EPEL policies <ref>https://fedoraproject.org/wiki/EPEL_Package_Maintainers</ref> <ref>https://fedoraproject.org/wiki/EPEL:Packaging?rd=Packaging:EPEL EPEL packaging guidelines</ref> <ref>https://fedoraproject.org/wiki/EPEL_Updates_Policy EPEL Updates policy</ref> <ref>https://fedoraproject.org/wiki/EPEL_incompatible_upgrades_policy EPEL incompatible upgrades policy</ref>
-# Create a package review request [http://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_Your_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
-# fedora-review flag is blank, nobody is reviewing the package yet
-# be patient until you find a reviewer, they will set fedora-review flag to '?'
-# fix any issues, and be patient until the package is fully reviewed
-# when package is approved the flag will be set to '+'
-== Upload the package to rawhide ==
-# 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)
-# create a SCM admin request [http://fedoraproject.org/wiki/Package_SCM_admin_requests 15] by setting the fedora-cvs flag to '?' and using the exact template from the official documentation [http://fedoraproject.org/wiki/Package_SCM_admin_requests 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
-# about a day later an admin will set the fedora-cvs flag to '+'
-# at this point the repository should be created, and you can track the status at https://admin.fedoraproject.org/pkgdb/package/<yourpackage>
-# some time later the package will show up on https://apps.fedoraproject.org/packages/<yourpackage>
-# use fedpkg to import the package, push the changes and request a koji build for rawhide [http://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Get_Sponsored 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
-# you can use 'koji download-build' to get the built package
-== Upload the package to Fedora release branches ==
-# read the update policy [http://fedoraproject.org/wiki/Updates_Policy 17]
-# 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
-# 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
-# your request will show up in bodhi as PENDING [https://fedoraproject.org/wiki/Bodhi#Pending 18] https://admin.fedoraproject.org/updates/<package-name>
-# be patient, there might be an extra day or so delay when the package is being pushed
-# the package will go through the following states in bodhi [https://fedoraproject.org/wiki/Bodhi#Pending 18]
-# taskotron will run some automated tests on your package, giving it negative karma if it fails them
-# at some point it will start to get pushed &quot;This update is currently being pushed to the Fedora N testing updates repository.&quot;
-# a (human) release engineer signs the PENDING updates and they get pushed to TESTING (on an almost daily basis?)
-# 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)
-# any fedora user with a FAS account can provide feedback (karma)
-# 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 ==
-{{admon/warning|TBD|where to get approval, what is the exact lifecycle for an EPEL package}}
-# [https://fedoraproject.org/wiki/EPEL_Package_Maintainers]
+= New packager =
-# [https://fedoraproject.org/wiki/EPEL:Packaging?rd=Packaging:EPEL EPEL packaging guidelines]
-# [https://fedoraproject.org/wiki/EPEL_Updates_Policy EPEL Updates policy]
-# [https://fedoraproject.org/wiki/EPEL_incompatible_upgrades_policy EPEL incompatible upgrades policy]
-== What is a package's status? ==
+# 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.
+# Create a bugzilla account <ref>https://bugzilla.redhat.com/createaccount.cgi</ref>
+# Create a FAS account <ref>https://admin.fedoraproject.org/accounts</ref>
+# Login to FAS and sign the CLA, upload your public SSH key, and (optionally) your OpenPGP key
+# Consult the documentation <ref>http://fedoraproject.org/wiki/Join_the_package_collection_maintainers</ref>
+# At this point you can submit your package review request
+#* Make sure to block the '''FE-NEEDSPONSOR''' bug if you are not yet sponsored into the packager group (i.e. this is your first package)
+# Inform upstream that you are packaging their software
+# Join the relevant mailing lists <ref>http://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Becoming_a_Fedora_Package_Collection_Maintainer</ref> <ref>https://lists.fedoraproject.org/mailman/listinfo</ref>
+# Send a self-introduction email <ref>http://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Introduce_yourself</ref>
+# Respond to bugzilla comments until your package is approved
+# Get sponsored into the packager group (you will get an email when this is done) <ref>http://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Get_Sponsored</ref> <ref>http://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group</ref>
+# Read the package maintenance guide and upload your package <ref>http://fedoraproject.org/wiki/Package_maintenance_guide</ref>
+# Submit your package to (branched) releases using Bodhi
-# Search for package name on https://apps.fedoraproject.org/packages/ Found -&gt; package is part of Fedora already
+= References =
-# Open https://admin.fedoraproject.org/updates/<your-package-name> Found -&gt; package has a Bodhi update request PENDING -&gt; TESTING -&gt; STABLE
+<references/>
-# Open https://apps.fedoraproject.org/packages/<your-package-name> Found -&gt; package has (non-scratch) Koji builds
-# Open https://admin.fedoraproject.org/pkgdb/package/<your-package-name> Found -&gt; package has SCM repo
-# Search on http://fedoraproject.org/PackageReviewStatus Found -&gt; a package review request exists on bugzilla
-# 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
-# All of the above searches fail: there is no package (review) yet

Search

Fedora Package Lifecycle notes: Difference between revisions

Latest revision as of 22:19, 20 March 2015

Contents

Fedora package lifecycle

EPEL package lifecycle

New packager

References