Package maintainer responsibilities
- How long to maintain?
- Belong to the appropriate low-traffic mailing list
- Manage security issues
- Work with upstream
- Work with Testing
- Deal with reported bugs in a timely manner
- Package updates
- Mentor and watch over co-maintainers
- Bot accounts
- Track dependency issues in a timely manner
- Notify others of changes that may affect their packages
- Respect Schedules
- Leaving Fedora
- Miscellaneous Items
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.
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.
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.
Package maintainer should handle security issues quickly, and if they need help they should contact the Security Response Team.
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.
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
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
The Package update policy provides guidance for maintainers who are updating packages in Rawhide, in "branched releases", and in the already-released "stable" branches.
In summary, however, maintainers should bear in mind that:
Releases should go from less conservative (Rawhide) to more so (the oldest supported stable release).
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.
Fedora users who do not update automatically may review the descriptions attached to updates before choosing whether they should apply them.
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.
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.
In the case when an automatic process is used in lieu of normal maintainer actions, a separate bot account should be used. The name of the account should end in "bot". The maintainers setting up the bot must create a wiki page for the bot account (https://fedoraproject.org/wiki/User:<bot>) with contact information to the maintainers and an explanation of what the bot does. If the updates submitted by the bot are causing problems that require immediate attention, rel-eng may disable the account temporarily.
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.
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.
Each Fedora release has a schedule indicating, among others, freezes such as string freeze. When creating a new package or updating an existing package, the release planning has to be respected.
We all know that priorities change throughout life. Seeing a valued contributor leaving makes us sad, but it may happen. Prior to departing, please consider performing the following steps:
Announce in the devel mailing list that you’re leaving, along with the list of packages that will be orphaned.
If someone shows interest in adopting any of your packages, give it to them.
Orphan all packages where you’re the primary admin, allowing someone else to step in and take them.
Open a FESCo ticket asking for your account to be removed from the
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.