Package Review Policy

Purpose

In order for a new package to be added to Fedora, the package must first undertake a formal review. The purpose of this formal review is to try to ensure that the package meets the quality control requirements for Fedora. This does not mean that the package (or the software being packaged) is perfect, but it should meet baseline minimum requirements for quality.

Applicability

Reviews are done for:

  1. New packages,

  2. Package renames,

  3. Old packages that were once retired returning to the collection,

  4. Packages merged from the old Fedora Core repository.

Some new packages are exempt from the review process. The Packaging Committee maintains the list of criteria.

The Packaging Committee can grant exceptions to the normal package review process. This may happen, for instance, if a large number of similar packages are being submitted at once or if a package is being updated to a new major version while the old version is being kept in the distribution with a different name. The process for granting exceptions is described at Packaging Committee#Review Process Exemption Procedure.

Review roles

There are two participant roles in the review process, the Contributor and the Reviewer. Other people are also allowed to comment on the review on informal basis.

The Contributor is someone who wants to submit and maintain a new package in Fedora. There are no restrictions on who can submit a package for review. However, the review can only be accepted if the Contributor is member of the packager group. This may mean that the Contributor has to Get Sponsored into the Package Group while the review is in progress.

The Reviewer is someone who chooses to review a package. The Reviewer must be a member of the packager group when the review starts.

Review process

The package submitted by the Contributor must adhere to the Packaging Guidelines. It must not be in list of Forbidden Items.

The Contributor requests a review of their package by making its specfile and SRPM available in a public url and posting a review request in Bugzilla as described in Package Review Process.

The Reviewer finds the package by looking for unassigned reviews and assigning themselves to it. The Contributor may also actively ask for a review if needed. These tasks are described in the Package Review Process.

The Reviewer reviews the package based on Packaging Guidelines, in particular Review Guidelines. A package that does not violate any MUST items can be approved. Violations of SHOULD items do not prevent approval, but a reasonable attempt should be made to satisfy them. The Reviewer can also comment on other items not covered by the guidelines. Such additional comments must not affect approval of the package.

The Contributor must address any issues raised by the Reviewer until the Reviewer is satisfied with the package. The Contributor should also consider the possible informal feedback given by other people. However, the review is ultimately between the Contributor and the Reviewer, with the Reviewer judging if the package can be approved or not.

The review continues until one of the following conditions are met:

  • The Reviewer is satisfied with the package and approves it.

  • The Reviewer determines that the package cannot be approved for some reason and rejects it.

  • The review stalls as described in Stalled reviews and is closed.

If the package is legally risky for whatever reason (known patent or copyright infringement, trademark concerns) the Reviewer must reject the review and leave an appropriate comment, (e.g. we do not ship codecs with patent issues). They must also mark the review as blocking FE-Legal.

Stalled reviews

Occasionally package reviews fail to make forward progress due to lack of response from one of the parties involved in the review. This policy addresses two classes of reviews: Those stalled because the review submitter is not responding, and those which have been assigned to a reviewer but are stalled because that reviewer is not responding. The idea is to move the ticket to a state where other interested parties can submit the package or take over the review. Of course there is no intent to punish anyone, and tickets can always be assigned back to the same reviewer or reopened.

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 nobody@fedoraproject.org (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.