Docs/package-maintainer-docs
1
0
Fork 0
Code Issues 12 Pull requests 3 Projects Releases Packages Wiki Activity Actions

Refer to FESCo package review policy

Browse source 
Recently, the Package Review Policy was added to FESCo docs,
mostly based on review pages of this repo.
Add reference to the FESCo policy
so that it is clear where need to do reviews comes from.
Also remove some content that does not have to be duplicated here
since it is already available at the FESCo policy.
This commit is contained in:
Otto Urpelainen 2021-09-05 14:16:55 +03:00
parent 271433235a
commit f37c55c892
3 changed files with 14 additions and 80 deletions
Download patch file Download diff file Expand all files Collapse all files

1
modules/ROOT/nav.adoc
View file

@ -5,7 +5,6 @@
** xref:New_Package_Process_for_Existing_Contributors.adoc[for Existing Contributors]
** xref:New_Package_Process_for_New_Contributors.adoc[for New Contributors]
* xref:Package_Review_Process.adoc[Package Review Process]
** xref:Policy_for_Stalled_Package_Reviews.adoc[Policy for Stalled Package Reviews]
* xref:Package_Renaming_Process.adoc[Package Renaming Process]
* xref:Package_Orphaning_Process.adoc[Package Orphaning Process]
* xref:Package_Retirement_Process.adoc[Package Retirement Process]

40
modules/ROOT/pages/Package_Review_Process.adoc
View file

@ -3,34 +3,9 @@ include::{partialsdir}/attributes.adoc[]
= Package Review Process
:toc:
[#review_purpose]
== Review 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.
Reviews are currently done for
totally new packages,
xref:Package_Renaming_Process.adoc#re_review_required[package renames],
old packages that were once retired returning to the collection,
and packages merged from the old Fedora Core repository.
Note that some new packages may be exempt from the review process.
Please see https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process[the list of criteria].
If an exemption is warranted,
the contributor can skip directly to
requesting a repository for it.
The request to create a repo should include the `--exception` flag
instead of a bug number:
....
fedpkg request-repo --exception <package-name>
....
The process is governed by the FESCo approved https://docs.fedoraproject.org/en-US/fesco/Package_review_policy/[Package Review Policy].
[#review_process]
== Review Process
@ -39,6 +14,19 @@ 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.
[#exemptions]
=== Exemptions
Certain packages are exempted from the review process
as described in the https://docs.fedoraproject.org/en-US/fesco/Package_review_policy/#what[Applicability section of Package Review Policy].
If an exemption is warranted,
the contributor can directly request a repository for the package.
The request to create a repo should include the `--exception` flag
instead of a bug number:
....
fedpkg request-repo --exception <package-name>
....
=== Contributor
A Contributor is defined as someone who wants to submit

53
modules/ROOT/pages/Policy_for_Stalled_Package_Reviews.adoc
View file

@ -1,53 +0,0 @@
// Imported from: https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews
= Policy for Stalled Package Reviews
:toc:
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]
== 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]
== 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 https://bugzilla.redhat.com/show_bug.cgi?id=FE-DEADREVIEW[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.