Package Review Process
Author: Tom 'spot' Callaway and others
Initial Draft: 2007-03-12
Last Revised: 2009-09-24
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.
Reviews are currently done for totally new packages, package renames, and packages merged from the old Fedora Core repository.
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.
A Contributor is defined as someone who wants to submit (and maintain) a new package in Fedora. To become a contributor, you must follow the detailed instructions to Join the package collection maintainers.
As a Contributor, you should have already made a package which adheres to the Package Naming Guidelines and Packaging Guidelines. There are also some packages that cannot be included in Fedora, to check if your package applies, check if it contains any Forbidden items.
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:
- Put your spec file and SRPM somewhere on the Internet.
- Fill out a request for review in bugzilla. The form is here. This is what a sample bugzilla request for review looks like:
- If you do not have any package already in Fedora, this means you need a sponsor. You need to add FE-NEEDSPONSOR to the bugs being blocked by your review request
- 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.
- There may be comments from people that are not formally reviewing the package, they may add NotReady to the Whiteboard field, indication that the review request is not yet ready, because of some issues they report. After you have addressed them, please post the URLs to the updated SPEC and SRPM file and remove it from the Whiteboard
- A reviewer takes on the task of reviewing your package. They will set the fedora-review flag to ?
- The reviewer will review your package. You should fix any blockers that the reviewer identifies. Once the reviewer is happy with the package, the fedora-review flag will be set to +, indicating that the package has passed review.
- At this point, you need to request CVS branches for your newly approved package with CVS admin requests
- When the CVS admin requests are complete, you can import your package into CVS.
- Cvs checkout the package, do a final check of spec file tags, etc, and run "make tag".
- Request a build by running "make build".
- Repeat the process for other branches you may have requested.
- Request updates for Fedora release branches, if necessary, using "make update" or another Bodhi interface as detailed in Bodhi Guide.
- You should make sure the review ticket is closed. You are welcome to close it once the package has been built on the requested branches, or if you built for one of the Fedora release branches you can ask Bodhi to close the ticket for you when it completes the process. If you close the ticket yourself, use NEXTRELEASE as the resolution.
You do not need to go through the review process again for subsequent package changes.
The Reviewer is the person who chooses to review a package.
The Reviewer can be any Fedora account holder, who is a member of the packager group. There is one exception: If it is the first package of a Contributor, the Reviewer must be a Sponsor. You can check if a Contributor has already been sponsored by looking the e-mail address up in the packager group of the account system.
- Search for a review request that needs a reviewer: PackageMaintainers/UnassignedReviewRequests (fedora-review flag is blank or the bug is assigned to email@example.com)
- If you notice some issues that need to be solved before you want to start a formal review, add these issues in a comment and set the Whiteboard of the bug to contain NotReady. This helps other possible reviewers to notice that the review request is not yet ready for further review action.
- if you want to formally review the package, set the fedora-review flag to ? and assign the bug to yourself.
- Review the package.
- 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. Mark the bug as NEEDINFO while waiting for the reviewer to respond to improvement requests; this makes it easier for reviewers to find open reviews which require their input.
- ACCEPT: If the package is good, set the fedora-review flag to +
- Once a package is flagged as fedora-review + (or -), the Reviewer's job is done although they may be called upon to assist the Contributor with the import/build/update process and to sure that the Contributor closes the ticket out when the process is complete.
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.|
Special blocker tickets
There are a few tickets which can be placed in the "Blocks" field to indicate specific ticket statuses:
|FE-NEEDSPONSOR||The submitter requires a sponsor; the review should only be done by a sponsor.|
|FE-DEADREVIEW||The review has been closed out because the submitter has left; users looking for packages to submit may find some possibilities in these dead tickets.|
|FE-Legal||The package is currently awaiting review by the legal team.|
To save time for reviewers, the page at http://fedoraproject.org/PackageReviewStatus/NEW.html will hide certain tickets which are not reviewable. The Whiteboard field can be used to mark a ticket with various additional bits of status which will cause it to be hidden or displayed differently.
|NotReady||The package is not yet ready for review. It is possible to open a review ticket, mark it as NotReady, and continue to work on it until it's ready to be seen by a reviewer.|
|BuildFails||The package fails to build.|