Package maintainers take care of the packages in Fedora. This includes both the packaging of upstream software into Fedora rpms and working with upstream to improve the software in various ways.

How long to maintain?

Each Fedora release lasts at least 13 months until it reaches end of life. A package maintainer is responsible for the package for at least this length of time. Refer to Fedora Release Life Cycle for more details.

Belong to the appropriate low-traffic mailing list

Package maintainers will receive important announcements through the moderated devel-announce mailing list. Maintainers will be automatically subscribed to this list. Everyone that is a primary maintainer of a package in Fedora is also strongly encouraged to subscribe to the devel list, though this is not mandatory.

Manage security issues

  • Package maintainer should handle security issues quickly, and if they need help they should contact the Security Response Team.

Work with upstream

It is recommended that package maintainers work closely with upstream wherever possible. This can include:

  • Send any changes to upstream.

  • Participate on the upstream mailing list.

  • Get an account on upstream bug trackers.

  • Forward severe bugs upstream when possible for assistance.

Refer to staying close to upstream projects for more information on this.

Work with Testing

There are lots of places for package maintainers to interface with QA to improve the quality of Fedora. It is recommended that maintainers:

  • On package submission, provide information to QA on how to debug/triage the package, for use for bug submitters and triagers

  • Provide test cases of general functionality, for use when testing for regressions

  • On update submission, provide test cases for things fixed in the update, for testers to use

Deal with reported bugs in a timely manner

  • If you find yourself unable to handle the load of bugs from your package(s), please ask for assistance on the devel and/or test lists. Teaching triagers about how to triage your bugs or getting help from other maintainers can not only reduce your load, but improve Fedora. Consider reaching out for some (more) co-maintainers to assist as well.

  • If there are bugs which you aren’t capable of fixing yourself because they deal with intricacies of the source code which you don’t fully understand, then you still need to address these bugs. It can be helpful to work with the upstream maintainer of the code, obtain help from more code-oriented people on fedora-devel, or check other distributions for patches. Always be sure to post to the bug report what you have done so that the reporter knows what it happening and what to expect. It is recommended that non-coder packagers should find co-maintainers who are familiar with the programming language used by their package(s), and can help with such bugs as a kind of 'second line support'.

  • Try and solve bugs or issues for the release against which they were reported, or if that is impractical note to bug reporters why their bug cannot be fixed in that release

Package updates

Package update guidelines provides guidance for maintainers updating packages on an already-released branch. In summary, however, maintainers should bear in mind that:

  1. Many Fedora users update automatically, so it is most important that an update doesn’t cause a users' applications or system to stop working suddenly.

  2. Fedora users who do not update automatically may review the descriptions attached to updates before choosing whether they should apply them.

  3. Not all Fedora users have good Internet bandwidth available and may prefer a single update with multiple changes rather than many updates in a short period.

Mentor and watch over co-maintainers

When you take on co-maintainers you enter into a partnership with them. They are able to work on the package which takes some of the burden off of you but you need to also be prepared to both help them along and make sure they aren’t committing any grevious mistakes. So do be available to answer questions that the co-maintainers may have and also keep an eye on the changes they make to the package to keep issues from cropping up unexpectedly.

Watching over the changes to your package also goes for changes made by people who are not explicit co-maintainers if you have opened your package for any packager to commit to.

You can also take on co-maintainers that are not yet sponsored into the packager group provided that you agree to mentor them in the ways of packaging for Fedora: teaching them both about the tools we use and the packaging guidelines they need to follow. See the How to get sponsored page for details on getting a new packager sponsored if you are not a sponsor yourself.

Track dependency issues in a timely manner

  • In Rawhide, updates to packages may cause other packages to have broken dependencies. Maintainers will be alerted when this happens, and should work to rebuild their packages with all due haste. Broken dependencies may leave end user systems in a state where no updates will be applied. In order to keep the distribution in a reasonable state, someone will step in and rebuild packages that have had dependency issues for some time, but package maintainers should not rely on these rebuilds.

Notify others of changes that may affect their packages

  • Some packages are depended upon by others; in this case, changes to one package may cause issues for others. Maintainers should be aware of the effects that changes to their packages may have, and should alert to the fedora-devel-announce mailing list of updates which contain ABI or API changes which may cause dependency problems for other packages. The announcement should occur a week before the packages update, so all maintainers affected are notified. The announcement should include the following information:

    • Nature of the change.

    • Branches (Rawhide, F9, etc.) which will be affected by the change.

    • Expected date of the change.

    • List of packages which are affected by the change. Generally, this is merely the list of packages which depend directly on the package which is being updated, and can be found with repoquery --whatrequires <package> where <package> is the package being updated.

    • If your package upgrade breaks other packages in Rawhide, you should try to help fix the packages affected. For example, if you’re a provenpackager, queue the rebuilds yourself.

Respect Schedules

Each Fedora release has a schedule indicating, among others, freezes such as string freeze : see for example planning for F20. When creating a new package or updating an existing package, the release planning has to be respected.

Miscellaneous Items

  • Maintainers need to maintain an upgrade path for their packages.

F(current-1) → F(current) → Rawhide

  • Packages should be pushed to the Rawhide branch first. If it builds and works fine for a few days, then it can be pushed to F(current). If there is a good reason to push it to F(current-1), it should be done after a few days of being in F(current).

  • When releasing a new package to a stable release branch, they should be pushed to the testing repo first in most cases.