Development/Schedule/MaintainerResponsibilityPolicy
From FedoraProject
< Development | Schedule
Responsibilities of maintainers of packages in Fedora Extras
Owner
bpepple
Target
May 2008
Status
- Approved by FESCo. Need to move to main wiki.
Proposal
Below this line:
Maintainer responsibility policy
How long to maintain?
13 months from initial Fedora release.
Belong to the appropriate low-traffic mailing list
- Package maintainers will receive important announcements through the moderated fedora-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 fedora-devel list, though this is not mandatory.
- http://www.redhat.com/mailman/listinfo/fedora-devel-announce
- http://www.redhat.com/mailman/listinfo/fedora-devel-list
Manage security issues
- Package maintainer should handle security issues quickly, and if they need help they should contact the Security Response Team.
- http://fedoraproject.org/wiki/Security/ResponseTeam
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 fedora-devel and/or fedora-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'.
Maintain stability for users
- Package maintainers should limit updates within a single Fedora release to those which do not require special user action. Many users update automatically, and if their applications stop working from no action of their own then they will be upset. This goes doubly for services which may break overnight.
- Package Maintainers should not push every single upstream update to all branches. Examine the changes in each upstream release and ask if the update is worth download and update time for many users. For upstreams that update very often with many small updates, consider waiting and updated only when the amount of changes is worth updating.
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 --alldeps 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, when Python-2.5 was integrated into Rawhide, Jeremy Katz at least fixed the important packages and queued a rebuild for all the other packages affected.
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.
Comments
- ideas/braindump from knurd (need a more detailed describtion if we really want them)
- in a stable tree try your best to not break other peoples packages
