From Fedora Project Wiki

Revision as of 09:58, 28 May 2008 by Till (talk | contribs) (fix wiki syntax)

Author: Tom 'spot' Callaway
Revision: 0.02
Initial Draft: Monday Mar 12, 2007
Last Revised: Monday Sep 03, 2007



Review Purpose

In order for a new package to be accepted into CVS, that 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.

Review Process

There are two roles in the review process, that of the contributor and that of the reviewer. In this document, we'll present both perspectives.

Contributor

A Contributor is defined as someone who wants to submit (and maintain) a package in Fedora.

As a Contributor, you should have already made a package which adheres to the Package Naming Guidelines and Packaging Guidelines . You should also be aware of ForbiddenItems. If you are unsure how to become a contributor, you should read PackageMaintainers/Join .

When you're happy with your spec file, you should then submit that SRPM to a package review. Currently, this is done by following these steps:

  1. Put your spec file and SRPM somewhere on the Internet.
  2. Fill out a request for review in bugzilla. The form is here: https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora&format=extras-review

Here is what a sample bugzilla request for review looks like:

File:PackageReviewProcess review.png

  1. Wait for someone to review your package! At this point in the process, the fedora-review flag is blank, meaning that no reviewer is assigned.
  2. A reviewer takes on the task of reviewing your package. They will set the fedora-review flag to ?
  3. The reviewer will review your package. You should fix any blockers that the reviewer identifies. Once the reviewer is happy with the package, they will set the fedora-review flag to +, indicating that the package has passed review.
  4. At this point, you can request CVS branches for your newly approved package here: ["CVSAdminProcedure"]
  5. When the ["CVSAdminProcedure"] is complete, you can import your package into CVS.
  6. Cvs checkout the package, do a final check of spec file tags, etc, and run "make tag".
  7. Request a build.
  8. Once the package is built, close the bugzilla review ticket as NEXTRELEASE.

You do not need to go through the review process again for subsequent package changes.

Reviewer

A Reviewer is defined as the person who chooses to review a package. For the sake of clarity, one person takes ownership of the review. Other people are encouraged to comment on the review as well, either in the bug or on the mailing list. The primary Reviewer can be any Fedora account holder with fedorabugs access, unless the Contributor is a first timer.

  • If you wish to be a Reviewer, make sure you have the proper permissions on your Fedora account. Follow the steps below.
  • Go to: https://admin.fedoraproject.org/accounts/
  • Click the "Edit your account" link
  • Go to the "Add new membership" section and fill out the fields as follows
  • Groupname: fedorabugs
  • Role type: user
  • Role domain: -empty-
  • If the Contributor is not sponsored, the review must be done by a Sponsor. You can check if a Contributor has already been sponsored by looking in the cvsextras group of the account system .

As a Reviewer, your job is to review the packages submitted in bugzilla request for reviews. You can see all the packages that need a reviewer by going here:
PackageMaintainers/UnassignedReviewRequests

So, starting with a new review request (fedora-review flag is blank):

  1. Set the fedora-review flag to ?
  2. Assign the bug to yourself.
  3. Review the package.
  1. Take one of the following actions:
  • ACCEPT: If the package is good, set the fedora-review flag to +
  • If the Reviewer is also acting as Sponsor for the Contributor, then this is the time to sponsor the Contributor in the account system .
  • FAIL, LEGAL: If the package is legally risky for whatever reason (known patent or copyright infringement, trademark concerns) close the bug WONTFIX and leave an appropriate comment (i.e. we don't ship mp3, so stop submitting it). Set the fedora-review flag to -, and have the review ticket block FE-Legal.
  • FAIL, OTHER: If the package is just way off or unsuitable for some other reason, and there is no simple fix, then close the bug WONTFIX and leave an appropriate comment (i.e. we don't package pornography for redistribution, sorry. Or, this isn't a specfile, it's a McDonald's menu, sorry.) Set the fedora-review flag to -.
  • NEEDSWORK: Anything that isn't explicitly failed should be left open while the submitter and reviewer work together to fix any potential issues.
  1. Once a package is flagged as fedora-review + (or -), the Reviewer's job is done.

Things To Check On Review

The Fedora Packaging Committee provides a list of things that MUST and SHOULD be checked on review. This list can be found here: Review Guidelines

Definitions for fedora-review Flag Settings

fedora-review (BLANK) Package Needs Review
fedora-review ? Package Under Review
fedora-review - Package Failed Review, dropped for legal or other issues.
fedora-review + Package Approved

Tracking of Package Requests