From Fedora Project Wiki

(Add link to bodhi command to request changing update status)
(update this thing for the current goddamn millennium, cut out a bunch of shit that should be in one of the *two* 'how to use git' pages)
Line 1: Line 1:
{{admon/note |  Run git config --global --add push.default tracking which instructs git to "push" to whatever branch you are tracking }}
This document shows how to update a package you maintain in Fedora.  It assumes you already have a package in the Fedora repositories.
This document shows how to update a package you maintain in Fedora.  It assumes you already have a package in the Fedora repositories.


This document is divided in three sections to give Developers, Testers, and Mirror Admins some guidelines on how to submit packages for [[Releases/Rawhide | <code>rawhide]], development</code> and <code>pending</code>.
* For details of the policy on requirements for updates at various stages of the [[Fedora Release Life Cycle]], refer to [[Updates Policy]].
 
* For more guidance on package updates, refer to [[Updates_Policy]].


== Overview ==
== Overview ==


Here you can find detailed information on process of Package Management in Fedora. If you want to know the difference between [[Releases/Rawhide | <code>rawhide]], development</code> and <code>pending</code> , and which one is suitable for you, along with an overall understanding of the release naming and repos, visit our new and improved [[ReleaseEngineering/Overview | Fedora Development Process Overview]] page.  
This page is intended for new and existing package maintainers. Testers and regular users may be interested in the [[QA:Updates_Testing|updates-testing]] repository and the [[QA:Update_feedback_guidelines|update feedback guidelines]]. This page specifically covers the update submission process. Refer to [[Using_Fedora_GIT|the package maintenance guide]] for some tips on day-to-day package maintenance.
 
New contributors (mandatory reading), new Testers (highly suggested reading), new Consumers (useful reading), or anybody interested in how Fedora is developed would find this page useful.


In particular, these are the '''new paths on mirrors''':
There are two significantly different package update submission workflows in Fedora:
* <code> /pub/fedora/linux/development/rawhide/ </code> will become the new path of Rawhide. It will continue to not have install images, and will be the place where builds from the <code> "devel" </code> branch in git go to. It'll be {{FedoraVersion|long|next}} intended content.
* <code> /pub/fedora/linux/development/{{FedoraVersion}} </code> will become the new path of the branched Fedora {{FedoraVersion}} content. This is where builds from the F-{{FedoraVersion}}/ branch in git will go after they pass through Bodhi as "stable".
* <code> /pub/fedora/linux/updates/testing/{{FedoraVersion}}/ </code> will be where potential Fedora {{FedoraVersion}} builds go after passing through bodhi as "testing". This is where you'll find the latest stuff proposed for ''freeze break'' and where testing and peer review of these freeze breaks will happen. When a maintainer feels enough testing has happened, or enough karma triggers the Bodhi auto request, the build will be marked "stable" and show up in the development/{{FedoraVersion}} tree at the next nightly compose.


(View [[No_Frozen_Rawhide_coming_soon | NFR coming soon! New paths on mirrors!]])
* [[Releases/Rawhide|Rawhide]], and [[Releases/Branched|Branched]] up to the [[Change deadlines|Alpha change deadline]]
* [[Releases/Branched|Branched]] releases after the Alpha change deadline, and stable releases


== For Developers ==
The repository layouts differ somewhat for Rawhide, Branched and stable releases, but the update workflows split up as described above.


{{admon/note|
== Rawhide and early Branched ==
If you want to build a new package, but you aren't sure if it should go to Rawhide or {{FedoraVersion|long|next}}, then:
# New packages should always be built at least for Rawhide
# New packages can be built for Pending and existing Fedora Releases, however they should go through updates-testing first. If the new package is critical-path it will require net positive karma from [[ReleaseEngineering | Releng]] / [[QA]] and peers as outlined below.}}
<!------------------------------------------------------ FIRST TABLE -------------------------------------------------------------->
{| border=1 align=left
|-
!
!valign=top| Check out and build from the devel/branch
!valign=top| No action required. Happens [[Releases/Rawhide#Nightly_live_builds | nightly automatically]]
!valign=top| Check out and build from the [https://admin.fedoraproject.org/updates/{{FedoraVersion|short|next}} {{FedoraVersion|short|next}}/branch] 
!valign=top| Request a testing update in [https://admin.fedoraproject.org/updates/ Bodhi] for {{FedoraVersion|short|next}}. Bodhi ''admins push'' it. 
!valign=top| Peers test the update and provide karma feedback via [https://admin.fedoraproject.org/updates/ Bodhi] 
!valign=top| Request a push to ''stable'' within [https://admin.fedoraproject.org/updates/ Bodhi]. Bodhi admins ''push'' it.
|-
|style="background-color:#DDDDDD" | Build for Rawhide
|style="background-color:#DEF3FE" align=center | X
| 
| 
| 
| 
|
|-
|style="background-color:#DDDDDD" | Build for Rawhide + testing in other branches
|
|style="background-color:#DEF3FE" align=center| X
| 
| 
| 
|
|-
|style="background-color:#DDDDDD"| Build non-critical path package for {{FedoraVersion|short|next}} (branched)
|
|
|style="background-color:#DEF3FE" align=center| X
| 
| 
| 
|-
|style="background-color:#DDDDDD"| Build critical-path for {{FedoraVersion|short|next}} (branched)
| 
| 
|style="background-color:#DEF3FE" align=center| X
| 
| 
|
|-
|style="background-color:#DDDDDD"| Push critical-path package waiting in "pending" updates-testing repo for a week without karma feedback
| 
|
|
|style="background-color:#DEF3FE" align=center| X<ref name="ref1">Mutually exclusive.</ref> 
| 
|style="background-color:#DEF3FE" align=center| X<ref name="ref1">Mutually exclusive.</ref>
|-
|style="background-color:#DDDDDD"| For a package, in critical path, in the "pending" updates-testing repo for a week that hasn't received karma feedback
| 
| 
|
| 
|style="background-color:#DEF3FE" align=center| X<ref name="ref2">Query [[QA|QA]]/[[ReleaseEngineering|Release Engineering]], too</ref> 
|
|-
|style="background-color:#DDDDDD"| To mark, built package for {{FedoraVersion|short|next}}, available for testing
|
|
| 
|style="background-color:#DEF3FE" align=center| X
|style="background-color:#DEF3FE" align=center| X
|
|-
|style="background-color:#DDDDDD"| To mark ''stable and tagged'' for {{FedoraVersion|short|next}} tested update 
|
|
| 
| 
| 
|style="background-color:#DEF3FE" align=center| X<ref name="ref3">Provided the package has net positive Karma from QA or releng and at least one more net positive karma point. If karma autopush is checked submit to stable is done automatically</ref>
|-
|style="background-color:#DDDDDD"| To push a package built to handle an urgent issue (e.g. security problem, non-functioning system, etc.)  to the {{FedoraVersion|short|next}} branch <ref name="ref4">In all cases, it's ''necessary''  to be very very very sure the update will not cause additional problems'''</ref>
|
|
|
| 
| 
|style="background-color:#DEF3FE" align=center|  X<ref name="ref5">If the package is not in the critical path, nor addressing a security problem, then it can be requested a push to stable<BR>
If the package addresses a security issue then it should be marked as security. Wait for the Security team to sign off on the update (not sure how this happens right now) before requesting the package be pushed to stable<BR>
If the package is in the critical path, then wait for a QA/Release Engineering/Peer net positive karma vote in Bodhi before requesting the package be pushed to stable</ref>
|}<BR>


Notes
The package update workflow for Rawhide and Branched before the Alpha freeze is simple:
----
<references/>
----
<BR>


<!------------------------------------------------------ SECOND TABLE -------------------------------------------------------------->
# Build the package with {{command|fedpkg build}} (see [[Using_Fedora_GIT]] for more details)
{| border=1 align=left
! || valign=top| File a buildroot override tag request as outlined in the [[Alpha_Freeze_Policy | Policy page]], and proceed to build the package || valign=top| Issue the [https://admin.fedoraproject.org/updates/ Bodhi] request || || || ||
|-
|style="background-color:#DDDDDD"| To build a package for the ''Pending'' {{FedoraVersion|short|next}} which requires a package not yet pushed ''stable'' for {{FedoraVersion|short|next}}||style="background-color:#DEF3FE" align=center| X ||style="background-color:#DEF3FE" align=center| X ||width="100px"| ||width="100px"| ||width="100px"| ||width="100px"|
|}


This is all you need to do. Your package will appear in the next daily compose of Rawhide or Branched and will be used in any image composes built from that tree.


== Later Branched and stable releases ==


{{admon/tip|
At the [[Change deadlines|Alpha change deadline]], the [[Bodhi]] update feedback system is enabled by [[ReleaseEngineering|Release Engineering]] and builds submitted with {{command|fedpkg build}} are no longer automatically sent to any official [[Fedora_repositories|repository]]. The update workflow for releases of this type is:
To check and see if the build will be in the {{FedoraVersion|long|next}}, as they will be tagged with ''"f1?"'', you can run ''koji latest-pkg f1?'' to see what the latest build of your package is for {{FedoraVersion|long|next}}.}}
<BR>


== For Testers ==
# Build the package with {{command|fedpkg build}}
{| border=1 align=left
# Submit an update for the package with {{command|fedpkg update}} or via the [https://admin.fedoraproject.org/updates/ Bodhi web interface]. This causes the package to be sent to the [[QA:Updates_Testing|updates-testing]] repository
!  || Read the [[Releases/Rawhide | Rawhide]] page and  follow instructions|| Keep the ''rawhide'' repo enabled and ''fedora'', ''updates'', & ''updates-testing'' repos disabled. || Consume the rawhide firehose and report issues as you find them.|| Install from Alpha, Beta, the Last Known Good ''Pending'' snapshot or a ''Pending'' nightly live image || <code>yum update</code> to the latest ''pending'' content || Update your Fedora 12 system by reading instructions at [[FIXME]] || Check the [[QA/Join]] page that describes the different testable repos, skill level and investment involved. || Read the [[QA:Package Acceptance Test Plan | Package Acceptance Test Plan]] and use it as a guideline
# After the update meets the criteria in the [[Updates Policy]], submit the update to ''stable'' with {{command|bodhi -R stable}} or the web interface


|-
At the time you submit the update, you may set a ''karma'' (feedback) level at which the update will automatically be submitted to ''stable''. This is optional. If you choose to use it, please carefully consider an appropriate feedback level. For a relatively obscure package which is quite stable, 1 or 2 may be an appropriate value. For a popular, sensitive and complex package such as {{package|firefox}} or the {{package|kernel}}, the default of 3 may be insufficient and a choice of 5 or even 10 may be appropriate.
|style="background-color:#DDDDDD"| To install Rawhide on your system to test the latest packages ||style="background-color:#DEF3FE" align=center| X ||style="background-color:#DEF3FE" align=center| X ||style="background-color:#DEF3FE" align=center| X || || ||  ||  ||
|-
|style="background-color:#DDDDDD"| To install and run {{FedoraVersion|long|next}} as your desktop and participate in test days ||  ||  || ||style="background-color:#DEF3FE" align=center| X ||style="background-color:#DEF3FE" align=center| X || ||  ||
|-
|style="background-color:#DDDDDD"| To update a Fedora 12 system to the ''Pending'' Fedora 13 for testing || || || || || ||style="background-color:#DEF3FE" align=center| X ||  ||
|-
|style="background-color:#DDDDDD"| To provide test feedback for new packages || || || || || ||  ||style="background-color:#DEF3FE" align=center| X ||
|-
|style="background-color:#DDDDDD"| To represent the [[QA]] team in providing feedback on critical path package updates || || || || || ||  ||style="background-color:#DEF3FE" align=center| X  ||style="background-color:#DEF3FE" align=center| X
|-
|}
[[Category:Package Maintainers]][[Category:How to]]
<BR>


{{admon/note| |
When a release is in '''Branched''' state, the ''updates-testing'' repository is enabled by default so most users will see the package, but only packages from ''stable'' are used in building milestone releases (Alpha, Beta and Final) and nightly images.
If you are a member of the QA FAS group, and provided positive feedback on a 'pending' or 'stable' package update.  The package update is released and includes a major regression.  What now?
# Review in weekly QA meeting.  It's ok, mistakes happen.
# Accident/omission.
# Misuse
}}


== For Mirror Admins ==
Where a package goes when it is marked as ''stable'' differs between '''Branched''' and '''stable''' releases. In '''Branched''' releases, ''stable'' packages are pushed to the base ''fedora'' repository. In '''stable''' releases, ''stable'' packages are pushed the ''updates'' repository. However, from the point of view of the packager, this is an insignificant implementation detail.
* If you are a mirror admin and want to prepare for additional repos coming to your mirror :
** Read <code>mirror-list(-d)</code> and watch for announcements regarding new paths being added to the Master Mirror.
** Check your ''sync exclusion settings'' to ensure you either get, or don't get the new path (depending on your needs).


== Build a package for Rawhide ==
When a release is in Stable state, the ''updates-testing'' repository is disabled by default, but [[QA]] team members and others run with it enabled in order to provide testing and Bodhi feedback. The main user population will see your update only when it passes Bodhi and reaches ''stable''.
To build a package for Rawhide, check it out from the git devel/branch.


Install fedora-packager if not already installed.
=== Branched milestone freezes ===


Check out a local working copy of the git module you plan to edit, e.g. (for a description of the directory layout, see the [[PackageMaintainers/Anatomy| Anatomy]] page:
For a short period before each milestone release, the ''stable'' repository is frozen. These periods are shown as the [[Change deadline]]s on schedules. During these periods, builds will not be pushed from ''updates-testing'' to ''stable'' even after being submitted manually or automatically. In the normal course of events, they will be pushed after the milestone release is approved at a [[Go_No_Go_Meeting]]. If you believe your update deserves to break a milestone freeze, a ''freeze exception'' may be granted through the [[QA:SOP_freeze_exception_bug_process|freeze exception process]]. Accepted release blocking bugs are granted the same status through the [[QA:SOP_blocker_bug_process|blocker bug process]].
<pre>fedpkg clone <package_name>
</pre>


{{Admon/important| Note: If you are not a member of the fedora packager group, you will receive a "permission denied" error.  Use the -a flag to clone anonymously. }}
{{admon/tip|  
 
If you are unsure whether your build is currently considered ''stable'' for a given release, you can check with {{command|koji latest-pkg fXX}} (where XX is the release).}}
{{Admon/important| Note: If you you use a separate ssh key for FAS, remember to load it into your ssh-agent. }}
 
* If you update to a new upstream version, you have to upload the tarball to an external lookaside cache. Operations on the lookaside cache require a client-side certificate, to get one, run:
 
<pre>fedora-cert -n</pre>
 
Edit your spec file manually to bump up the version or use <code>rpmdev-bumpspec</code>. Use <code>spectool -g package_name.spec</code> to get the new upstream source instead of using wget or other means. That way you make sure that the URL specified in the spec file is current. To upload a new source tarball and replace an older one, in the branch directory (i.e. devel in this case) run:
 
<pre>fedpkg new-sources /path/to/package_name.tar.gz
</pre>
 
or for multiple files:
<pre>fedpkg new-sources package_name.tar.gz package_name_tests.tar.gz
</pre>
 
You can omit the path if the source is the current directory.
 
This also updates your local copy of the '''.gitignore''' and '''sources''' files. You will need to do this for each branch  that you will be building the new version for, or alternatively you can merge the master branch in the other branches. The new tarball will be uploaded only once and the rest will be md5sum checked and not uploaded, only the '''.gitignore''' and '''sources''' files will be updated.
 
If you just want to add another tarball (e.g. a big gzipped patch or a documentation tarball), use:
<pre>fedpkg upload somefile.tar.gz
</pre>
Contrary to <code>fedpkg new-sources</code>, this does not purge old files from the <code>.gitignore</code> and <code>sources</code> files.
 
If you just have a small patch or otherwise plain text file, you can commit those directly to git.  This can be done with the <code>git add</code> command, e.g.:
<pre>git add packagename-fix-the-foobar.patch
</pre>
 
* Use the command <code>fedpkg mockbuild</code> to test a package build on your local mock system.  Then install and test the package.  If something doesn't work, fix it and repeat this step. You can also use the koji build system to do a scratch build perhaps for some arch you don't have locally. For example, to build just for x86_64:
<pre>fedpkg srpm
koji build --scratch --arch-override x86_64 f18 packagename-version-release.src.rpm
</pre>
 
* Check if everything that has changed is correct with the first command which shows diff of the change and the second command runs rpmlint against your spec file, srpm and binary RPMs to verify that it complies with packaging guidelines:
<pre>
fedpkg diff
fedpkg lint
</pre>
 
* Add any changes you made to the spec:
<pre>git add package_name.spec</pre>
 
* Generate Git commit from spec changelog, commit to devel branch and push in one go:
<pre>fedpkg commit -p -c</pre>
 
(or)
 
* Do the above steps one by one
 
<pre>fedpkg clog
fedpkg commit -F clog
fedpkg push
</pre>
 
As a test whether the full commit was fine, you can check out a fresh working copy into a different directory. It should succeed in fetching the binaries from lookaside cache and also pass simple build tests such as '''make i686''' or '''make srpm''' at least.
 
* Finally, instruct the builders to build your package for rawhide:
<pre>fedpkg build
</pre>
 
* Check the koji build page at http://koji.fedoraproject.org/koji/ for the build process.
 
=== Example ===
 
<pre>
fedpkg clone foo
cd foo
spectool -g foo.spec
fedpkg new-sources foo-0.0.2.tar.bz2
gedit foo.spec      # change the required things in the specfile. rpmdev-bumpspec is useful for simple version updates
fedpkg mockbuild    # check that the changes you made are correct
fedpkg diff
fedpkg lint
fedpkg commit -p -c  # commit and push in one go
</pre>
 
{{Admon/important| Note: Be careful that requesting a build on Rawhide is enough, when that build is successful, for that build to reach the Rawhide repository/build-root after a few hours. Before pressing the Enter key after the following command, it is not a bad idea to think again at the potential consequences on the other packages. }}
 
<pre>
# request build
fedpkg build
</pre>
 
The package builders publish your package in the <code>development</code> tree, also called "Rawhide."  If the package is a stable update, you may also provide it to users of the currently-maintained stable, or branched Fedora release.  To make it available to F-19 or F-20 users, or testers of the branched F-21 for example, use the procedure outlined in the [[#Working_with_packages_in_the_stable_branches|next chapter]].
 
An alternative may be used, [[PackageMaintainers/UsingCvsFaq#Import_of_complete_src.rpm_packages| the import of a complete src.rpm]].
 
More in-depth information on the build system is at
[[PackageMaintainers/UsingKoji| UsingKoji]].
 
=== Removing a package build from the devel branch ===
 
From time to time you may want to remove a package build you pushed to the devel branch (rawhide).  This could happen in a situation where a bug
or issue is found in your package that will be resolved upstream in the next release.  You may want to wait for this release instead
of back-porting a fix yourself, so pulling the broken package from rawhide makes sense.
{{admon/caution|Use this carefully!|This should only be done on the same day of the build.  If your build has already been published in rawhide you must not untag it!}}
 
You can remove the package from rawhide by using koji as follows:
 
<pre>
koji untag-pkg f20 foo-1.1.3-1.fc20
</pre>
 
Where <code>foo-1.1.3-1.fc20</code> is replaced with the name of your package build.  See <code>koji help</code> or [[PackageMaintainers/UsingKoji | UsingKoji]] for more information.
 
=== Requesting special dist tags ===
When updating a package affects a large number of dependencies (e.g. all perl, python, ruby or ghc packages) it may be better to initially do the builds in another repo, so that there is less disruption in rawhide.
 
If you think you have an update that falls under this case you can request a special dist tag by filing a [https://fedorahosted.org/rel-eng/newticket release engineering ticket]. Someone from release engineering will likely want to discuss your needs to make sure this is really an appropriate case (it's OK ask if you aren't sure) and that you get what you need.
 
= Working with packages in the stable branches =
Stable branches are branches within git for either released Fedoras, or a branched Fedora that is still in bugfix/polish mode but has not yet been released.
 
# Switch to the branch which you would like to update with the <code>fedpkg switch-branch</code> command. Here is an example of an update for {{FedoraVersion|long|current}}: {{command|fedpkg switch-branch f{{FedoraVersionNumber|current}}}}
# Make any required changes. In many cases, you can apply the same changes from the <code>devel/</code> branch to the other branches. Use the <code>diff</code> and <code>patch</code> utilities for this purpose.
# Use the command {{command|fedpkg local}} to test a package build on your local system.  Then install and test the package.  If something doesn't work, fix it and repeat this step.
# Commit the verified changes to the branch you are working on: {{command|git commit}} and {{command|git push}}. Example of {{command|git push}}: {{command|git push origin f{{FedoraVersionNumber|current}}:refs/heads/f{{FedoraVersionNumber|current}}/master}}. See also [[Using_Fedora_GIT#Branch_names | Fedora branch names]].
# Instruct the builders to build your package: {{command|fedpkg build}}
# Check the koji build page at http://koji.fedoraproject.org/koji/ for the build process.
 
* If you want to build a package for the Pending {{FedoraVersion|long|next}} but it requires package that is not yet pushed "stable" for {{FedoraVersion|long|next}}.
# You would need to file a buildroot override tag request as outlined in the policy page Alpha_Freeze_Policy
# Once tagged, you can proceed to build her package and issue the [[Package_update_HOWTO#Submit_your_update_to_Bodhi | Bodhi]] request
 
== Submit your update to Bodhi ==


# This can be accomplished in a few different ways.  The easiest being: {{command|fedpkg update}}. If your local username differs from that of your Fedora account, you will need to specify it with the following command: <code>BODHI_USER=foo fedpkg update</code> Or you add <code>export BODHI_USER=foo</code> to the file <code>~/.bashrc</code> and run the following command:
=== New package submissions ===
<pre>
source ~/.bashrc
fedpkg update
</pre>
## Alternatively, you can also submit your update using the [https://fedorahosted.org/bodhi/wiki/CLI bodhi-client]
## or the [https://admin.fedoraproject.org/updates web interface] .
# Once submitted, bodhi will automatically request that your update be pushed to updates-testing. Note that security updates follow a [[Security/TrackingBugs |slightly different process]] .
# A Release Engineer then signs and pushes out your updates.  The signing step is currently a manual process, so your updates will not be instantly released once submitted to bodhi.
# Once pushed to testing, people are able to +1/-1 the updates "karma", based on whether or not it seems to be functional for them.  If your update reaches a karma of 3 (default value, changeable before pushing out an update), it will automatically be pushed to stable.  Likewise, if it reaches -3 (default valie, changeable before pushing out an update), it will be automatically unpushed.  If your update does not receive enough feedback to automatically push it to stable, you will have to submit it as a final update yourself.  This can easily be done [https://fedorahosted.org/bodhi/wiki/CLI#Changingthestateofanupdate with the command-line tool], or with the web interface.
#  You will then be notified when your update has been pushed to stable.  Bodhi will close all associated bugs and send an announcement to fedora-package-announce.  At this point, your update has been officially released!


== Consider Creating a Package Test Plan ==
If you want to build a new package, but you aren't sure if it should go to Rawhide or {{FedoraVersion|long|next}}:


If you create wiki page containing a test plan for your package, and categorize it appropriately, it will be automatically linked in Bodhi, so that testers will have guidance about what to do to make sure a package update is okay.
* New packages should always be built for ''Rawhide'''
* New packages can be built for '''Branched''' and '''stable''' releases if adding them would provide value to users of those releases without significant risk of causing harm


Details on creating a test plan are found at [[QA:SOP_package_test_plan_creation]].
The submission process for new packages, after they have passed the [[Package_Review_Process]] and been [[Package_SCM_admin_requests|given an SCM repository]], is exactly the same as that for package updates.


== Get Automatically Notified on New Upstream Releases ==
== Consider creating a package test plan ==
To automatically get notifications via bugzilla whenever upstream has a new release, refer to [[Upstream_Release_Monitoring | upstream release monitoring]] page.


== Reference ==
If you [[QA:SOP_test_case_creation|create test cases]] for your package, and [[QA:SOP_package_test_plan_creation|categorize them appropriately]], they will be automatically linked in Bodhi, so that testers will have some guidance for planned update testing.


* http://fedoraproject.org/wiki/Using_git_FAQ_for_package_maintainers
[[Category:Package Maintainers]]

Revision as of 06:41, 25 September 2014

This document shows how to update a package you maintain in Fedora. It assumes you already have a package in the Fedora repositories.

Overview

This page is intended for new and existing package maintainers. Testers and regular users may be interested in the updates-testing repository and the update feedback guidelines. This page specifically covers the update submission process. Refer to the package maintenance guide for some tips on day-to-day package maintenance.

There are two significantly different package update submission workflows in Fedora:

The repository layouts differ somewhat for Rawhide, Branched and stable releases, but the update workflows split up as described above.

Rawhide and early Branched

The package update workflow for Rawhide and Branched before the Alpha freeze is simple:

  1. Build the package with fedpkg build (see Using_Fedora_GIT for more details)

This is all you need to do. Your package will appear in the next daily compose of Rawhide or Branched and will be used in any image composes built from that tree.

Later Branched and stable releases

At the Alpha change deadline, the Bodhi update feedback system is enabled by Release Engineering and builds submitted with fedpkg build are no longer automatically sent to any official repository. The update workflow for releases of this type is:

  1. Build the package with fedpkg build
  2. Submit an update for the package with fedpkg update or via the Bodhi web interface. This causes the package to be sent to the updates-testing repository
  3. After the update meets the criteria in the Updates Policy, submit the update to stable with bodhi -R stable or the web interface

At the time you submit the update, you may set a karma (feedback) level at which the update will automatically be submitted to stable. This is optional. If you choose to use it, please carefully consider an appropriate feedback level. For a relatively obscure package which is quite stable, 1 or 2 may be an appropriate value. For a popular, sensitive and complex package such as firefox or the kernel, the default of 3 may be insufficient and a choice of 5 or even 10 may be appropriate.

When a release is in Branched state, the updates-testing repository is enabled by default so most users will see the package, but only packages from stable are used in building milestone releases (Alpha, Beta and Final) and nightly images.

Where a package goes when it is marked as stable differs between Branched and stable releases. In Branched releases, stable packages are pushed to the base fedora repository. In stable releases, stable packages are pushed the updates repository. However, from the point of view of the packager, this is an insignificant implementation detail.

When a release is in Stable state, the updates-testing repository is disabled by default, but QA team members and others run with it enabled in order to provide testing and Bodhi feedback. The main user population will see your update only when it passes Bodhi and reaches stable.

Branched milestone freezes

For a short period before each milestone release, the stable repository is frozen. These periods are shown as the Change deadlines on schedules. During these periods, builds will not be pushed from updates-testing to stable even after being submitted manually or automatically. In the normal course of events, they will be pushed after the milestone release is approved at a Go_No_Go_Meeting. If you believe your update deserves to break a milestone freeze, a freeze exception may be granted through the freeze exception process. Accepted release blocking bugs are granted the same status through the blocker bug process.

If you are unsure whether your build is currently considered stable for a given release, you can check with koji latest-pkg fXX (where XX is the release).

New package submissions

If you want to build a new package, but you aren't sure if it should go to Rawhide or Fedora 42:

  • New packages should always be built for Rawhide'
  • New packages can be built for Branched and stable releases if adding them would provide value to users of those releases without significant risk of causing harm

The submission process for new packages, after they have passed the Package_Review_Process and been given an SCM repository, is exactly the same as that for package updates.

Consider creating a package test plan

If you create test cases for your package, and categorize them appropriately, they will be automatically linked in Bodhi, so that testers will have some guidance for planned update testing.

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