Reviews are currently done for totally new packages, [[Package_Renaming_Process#Re-review_required|package renames]], old packages that were once depreciated returning to the collection, 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.
审核过程有两种角色,一种是贡献人员一种是审核者。本文档将会详细说明这两者。
=== Contributor ===
=== 贡献人员 ===
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]].
贡献人员就是想要提交新软件包的人,又可以称之为提交者。如果想要成为一名贡献人员,您必须按照 [[Join the package collection maintainers/zh-cn|成为 Fedora 软件包仓库维护人员]] 的步骤来做。
As a Contributor, you should have already made a package which adheres to the [[Packaging:NamingGuidelines| Package Naming Guidelines]] and [[Packaging:Guidelines| 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.
如果您对您的 spec 文件很满意,那么可以开始审核流程,步骤如下:
Currently, this is done by following these steps:
<ol>
<ol>
<li> Put your spec file and SRPM somewhere on the Internet.
<li> 在互联网上放置好您的 spec 文件和 SRPM。
<li> Fill out a [https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora&format=fedora-review request for review in bugzilla]. For guidance, a [[:Image:PackageReviewProcess_review.png|screenshot of a sample bugzilla request is available for review]].
<li> If you do not have any package already in Fedora, this means you need a sponsor and to add FE-NEEDSPONSOR to the bugs being blocked by your review request. For more information read the [[How to get sponsored into the packager group]] wiki page.
<li> If you do not have any package already in Fedora, this means you need a sponsor and to add FE-NEEDSPONSOR to the bugs being blocked by your review request. For more information read the [[How to get sponsored into the packager group]] wiki page.
Line 41:
Line 40:
<li> When this is complete, you can [[Using git FAQ for package maintainers#How_do_I_import_a_SRPM_package.3F|import your package]] into the SCM.
<li> When this is complete, you can [[Using git FAQ for package maintainers#How_do_I_import_a_SRPM_package.3F|import your package]] into the SCM.
<li> Checkout the package using "fedpkg clone <package-name>" do a final check of spec file tags, etc.
<li> Checkout the package using "fedpkg clone <package-name>" do a final check of spec file tags, etc.
<li> Request a build by running "fedpkg build".
<li> 使用 "fedpkg build" 命令请求构建。
<li> Repeat the process for other branches you may have requested.
<li> 为其它分支重复之前的操作。
<li> Request updates for Fedora release branches, if necessary, using "fedpkg update" or another Bodhi interface as detailed in [[Bodhi]].
<li> Request updates for Fedora release branches, if necessary, using "fedpkg update" or another Bodhi interface as detailed in [[Bodhi]].
<li> 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.
{{admon/question|Time to sponsor?|If the Reviewer is also acting as Sponsor for the Contributor, then this is the time to sponsor the Contributor in the [https://admin.fedoraproject.org/accounts/ account system]}}
{{admon/question|Time to sponsor?|If the Reviewer is also acting as Sponsor for the Contributor, then this is the time to sponsor the Contributor in the [https://admin.fedoraproject.org/accounts/ account system]}}
<li> '''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.
<li> '''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 '''-'''.
<li> '''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.
<li> '''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.
</ul>
</ul>
<li> 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.
There are a few tickets which can be placed in the "Blocks" field to indicate specific ticket statuses:
少量支持单会在 "Blocks" 处有记录以表明特殊耳朵状态:
{| border="1"
{| border="1"
|-
|-
|FE-NEEDSPONSOR||The submitter requires a sponsor; the review should only be done by a sponsor.
|FE-NEEDSPONSOR||审核提交人需要保证人。注意审核过程只能有一位担保人。
|-
|-
|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.
|FE-Legal||该软件包被社区法律团队认定存在法律风险。
|}
|}
== The Whiteboard ==
== 白板(Whiteboard) ==
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.
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.
{| border="1"
{| border="1"
|-
|-
|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.
|AwaitingSubmitter||The package review is stalled and cannot proceed without input from the submitter.
|AwaitingSubmitter||审核卡住了,需要提交人更多信息。
|-
|-
|Trivial||The package is trivial to review. See below.
|Trivial||软件包比较琐碎。请见下。
|}
|}
The "Trivial" status is intended to indicate packages which, as an aid to new reviewers, are especially uncomplicated and easy to review. A ticket should not be marked as being trivial unless:
"Trivial" 状态打算表明该软件包,as an aid to new reviewers, are especially uncomplicated and easy to review. A ticket should not be marked as being trivial unless:
* The package is known to build and a link to a scratch build is included.
* The package is known to build and a link to a scratch build is included.
* The ticket explains any rpmlint output which is present.
* The ticket explains any rpmlint output which is present.
If you do not have any package already in Fedora, this means you need a sponsor and to add FE-NEEDSPONSOR to the bugs being blocked by your review request. For more information read the How to get sponsored into the packager group wiki page.
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.
Review Swaps If nobody comments on your review request, you might want to mail to a mailing list (for example, devel) asking for a "review swap". This is an offer to do a review of someone else's package in exchange for them reviewing your package. This is usually one-for-one, or can be some other private arrangement depending on the difficulty of the respective packages.
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. It is expected that you will respond to commentary, including updating your submission to address it; if you do not, your ticket will be closed.
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 make an SCM admin request for your newly approved package.
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.
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.
"Trivial" 状态打算表明该软件包,as an aid to new reviewers, are especially uncomplicated and easy to review. A ticket should not be marked as being trivial unless:
The package is known to build and a link to a scratch build is included.
The ticket explains any rpmlint output which is present.
The spec contains nothing which is unnecessary in modern Fedora (such as BuildRoot:, a %clean section or %defattr).
The spec is free from excessive or complicated macro usage.
The spec uses only the least complicated scriptlets which are taken directly from the Packaging:ScriptletSnippets page.
The package contains no daemons.
The package is not especially security sensitive.
The code has undergone a thorough inspection for licensing issues. Anomalies which would be found by licensecheck should be explained.
In short, this should be reserved only for those tickets which should be easily approachable by someone doing their first package review.