<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> 如果您尚未在 Fedora 中维护任何软件包，这时候您需要标记 bug 的 Blocks 为 FE-NEEDSPONSOR（177841）。详情请阅读 [[How to get sponsored into the packager group]]。
<li> 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.
<li> 等待某人审核您的软件包。At this point in the process, the '''fedora-review flag''' is blank, meaning that no reviewer is assigned.
{{admon/tip|Review Swaps| If nobody comments on your review request, you might want to mail to a mailing list (for example, {{fplist|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. }}
{{admon/tip|Review Swaps| If nobody comments on your review request, you might want to mail to a mailing list (for example, {{fplist|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. }}
<li> 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.
<li> 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.
Line 42:
Line 42:
<li> 使用 "fedpkg build" 命令请求构建。
<li> 使用 "fedpkg build" 命令请求构建。
<li> 为其它分支重复之前的操作。
<li> 为其它分支重复之前的操作。
<li> Request updates for Fedora release branches, if necessary, using "fedpkg update" or another Bodhi interface as detailed in [[Bodhi]].
等待某人审核您的软件包。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.
Review Swaps
退出审核
Time to sponsor?
