Package maintainer policy

From FedoraProject

Revision as of 13:33, 26 May 2008 by Timlau (Talk | contribs)

Jump to: navigation, search


Fedora Package Maintainers Policies

This document should give you a quick overview of all the relevant policies for Fedora Package Collection. It covers only the most important things -- each section has a link to a document with more detailed explanations and examples that outline how to lay out the rules. For a full list of documents see the end of this document .

On maintaining packages

Who is allowed to modify which packages

Normally the maintainer that is listed as primary maintainer in the PackageDB (formerly this was owners.list) of a package is the only one who modifies the package or gives others permission (e.g. by accepting them as co-maintainers) to commit and build changes for that package. Bugzilla is normally the best way to contact the package maintainer or to send him patches and suggestions because it is neutral and trackable; but poking people once or twice in IRC or directly via mail might be a good idea.

But there are certain exceptions where the maintainer has to accept that other packagers will modify his packages. Those exception are described in detail below -- it mostly boils down to this:


  • a packager doesn't fix important bugs in time
  • there are problems known that might be bad for the whole Project or a lot of users of the repo/a particular package
  • the changes are quite minor or considered as a general cleanup to a lot of packages

then provenpackagers are allowed to fix stuff in other peoples packages.

Read on for more more details about this topic .

What to do if a Maintainer is absent

  1. Check if the non-responsive maintainer is on vacation. To see if the maintainer has been recently active on Fedora, fedora-active-user can be employed.
  2. File a bug against the package in Bugzilla asking for the maintainer to respond. This bug should list the outstanding issues they need to address. This is a must.
  3. After every 7 days, the reporter adds a comment to the bug report asking again for a response. Others can add to the bug that they also were not successful in contacting the maintainer, or providing additional contact information for the maintainer (i.e., alternative email, IRC, etc).
  4. After 2 failed attempts (2 weeks of no response from the maintainer), the reporter posts to the Fedora devel list with a link to the bug report and asks if anyone knows how to contact the maintainer.
  5. After other 7 days (now 3 weeks total), the reporter posts a formal request to the FESCo trac with the bug link, indicating all reasonable efforts to contact the maintainer have failed and that they wish to take over the package.
  6. If at least one FESCo member approves the takeover, and no one objects within 3 days, the reporter may take over the package.
  7. Once approval has been given, follow Package SCM admin requests to request ownership of the package. In addition to this, the new owner must also reassign all open bugs for this package to themselves.

Read on for more more details about this topic


All packages in Fedora should normally be maintained by a group of maintainers. Ideally, each package normally should have at least three maintainers in total. There is one primary maintainer and a primary maintainer per distribution release (both often will be identical); each distribution maintainer should have at least one co-maintainer per release, to make sure there are actually at least two people for a package per each supported release. Maintainers should work towards getting at least one co-maintainer.

One important goal of co-maintainership in Fedora is to help getting new people involved into the project, while the experienced and respected maintainers get a chance to get involved with the often more complicated and more important parts of the project if they want to.

Read on for more more details about this topic

Special rules for Packages with kernel modules

  • Verify that there is an acceptable license for a kernel-module by asking on fedora-devel-list.
  • A kernel-module should be merged into the upstream kernel.
  • Open a review bug in bugzilla with an explanation from the maintainer of the kernel-module why it is not yet merged with the mainline kernel and a planned merge date.
  • Send FESCo an email asking for permission to allow the module in Fedora. FESCo will investigate and vote if the kernel-module is suitable for Fedora.
  • While anyone can review a kernel-module package, once it is set to APPROVED by the reviewer, a Fedora Sponsor or someone experienced with kernel modules should examine the package and post an additional approval notice before it is imported into CVS.

Read on for more more details about this topic

Fedora Maintenance Lifecycle Policy

  1. REDIRECTFedora_Release_Life_Cycle

Read on for more more details about this topic

Review workflow

What to do with stalled reviews

Reviewer not responding

  • When a review ticket is assigned to a reviewer who does not respond to comments for one month, a comment is added to the ticket indicating that the review is stalled and that a response is needed soon.
  • If there is no response within one week, the fedora‑review flag is set to the empty value. The ticket is reassigned to (use the Reassign bug to owner and QA contact of selected component radio button for this) with the intention to move the ticket back to a state where another reviewer can work on it.

Submitter not responding

  • When the submitter of a review ticket has not responded to comments for one month, a comment is added to the ticket indicating that the review is stalled and that a response is needed soon.
  • If there is no response within one week, the ticket is closed with resolution NOTABUG, and the fedora-review flag is set to the empty value.
  • The bug may be set as blocking FE-DEADREVIEW. The intention is to close the bug so that it can be submitted by someone else in a separate bug, and also to make it easy to find bugs closed in this way.

If the bug is resubmitted by someone else, it is also reasonable to change the resolution on the closed bug to DUPLICATE and mark it as a duplicate of the new bug so that reviewers of the new ticket can easily find the work that was done on the old one.

Read on for more more details about this topic


FESCo elections

PackageMaintainers/Policy/FESCoElections,, from="^

Read on for more more details about this topic

All approved Fedora policy documents

If you want more details look at the individual documents that cover the policies in depth: