#26 Refer to FESCo package review policy
Merged 2 years ago by oturpe. Opened 2 years ago by oturpe.
fedora-docs/ oturpe/package-maintainer-docs update-review-pages  into  master

Minor updates to Package Review Process
Otto Urpelainen • 2 years ago  
Refer to FESCo package review policy
Otto Urpelainen • 2 years ago  
file modified
-1
@@ -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]

@@ -3,41 +3,29 @@ 

  = 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

  

  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.

+ This document presents 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

  
@@ -48,11 +36,8 @@ 

  you must follow the detailed instructions to xref:Joining_the_Package_Maintainers.adoc[Joining the Package Maintainers].

  

  As a Contributor, you should have already made a package

- which adheres to the https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/[Package Naming Guidelines]

- and https://docs.fedoraproject.org/en-US/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 https://fedoraproject.org/wiki/Forbidden_items[Forbidden Items].

+ which adheres to the https://docs.fedoraproject.org/en-US/packaging-guidelines/[Packaging Guidelines]

+ and does not contain any https://fedoraproject.org/wiki/Forbidden_items[Forbidden Items].

  

  When you're happy with your spec file,

  you should then submit that SRPM to a package review.
@@ -78,7 +63,7 @@ 

  or can be some other private arrangement

  depending on the difficulty of the respective packages.

  

- * If you do not have any package already in Fedora, you need a sponsor.

+ * If you are not member of the https://accounts.fedoraproject.org/group/packager/[packager] group, you need a sponsor.

  Add https://bugzilla.redhat.com/show_bug.cgi?id=FE-NEEDSPONSOR[FE-NEEDSPONSOR] to the bugs being blocked by your review request.

  For more information read xref:How_to_Get_Sponsored_into_the_Packager_Group.adoc[How to Get Sponsored into the Packager Group].

  
@@ -107,22 +92,29 @@ 

  indicating that the package has passed review.

  

  * If you have not yet been sponsored,

- request sponsorship by https://pagure.io/packager-sponsors/new_issue[raising an issue at package sponsors].

+ request sponsorship by https://pagure.io/packager-sponsors/issues[raising an issue at packager-sponsors].

  

  * When your package passes the review

-  you should use `fedpkg` to request a Git repository for it.

-  Before you can request a Git repository for the package, 

-  you will need a https://pagure.io/settings/token/new[pagure api token]

-  with _Create a new ticket_ ACL

-  added into `~/.config/rpkg/fedpkg.conf`:

+ you should use `fedpkg` to request a Git repository for it.

+ Before you can request a Git repository for the package, 

+ you will need a https://pagure.io/settings/token/new[pagure.io api token]

+ with _Create a new ticket_ ACL

+ added into `~/.config/rpkg/fedpkg.conf`:

+ +

  ....

  [fedpkg.pagure]

  token = <generated-code>

  ....

  

  * Request a Git repository for the package.

- For example, if your bugzilla review ticket is 12345,

- use: `fedpkg request-repo  12345`.

+ For example, if the package name is `my-package`

+ and the bugzilla review ticket is 12345,

+ :

+ +

+ ....

+ fedpkg request-repo my-package 12345

+ ....

+ +

  Check that your review bug is valid.

  It must have the `fedora-review` set to `+`,

  and it must be assigned to your reviewer.
@@ -132,14 +124,19 @@ 

  and not just Rawhide,

  let's say to Fedora {MAJOROSVER},

  you can use the following command to request additional branches:

- `fedpkg request-branch --repo f{MAJOROSVER}`.

+ +

+ ....

+ fedpkg request-branch --repo f{MAJOROSVER}`

+ ....

+ +

  You must wait for your repository to be created

  before filing your branch request,

  otherwise your branch request will be closed as invalid.

  

- * When this is complete

- (https://pagure.io/releng/fedora-scm-requests/issues[tickets in Pagure] for requests above are closed as processed),

+ * When https://pagure.io/releng/fedora-scm-requests/issues[fedora-scm-requests tickets]

+ for the requested repository and branches are closed,

  checkout the package:

+ +

  ....

  fedpkg clone

  ....

@@ -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.

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.

Also some minor fixes to Packege Review Policy
in a separate commit.

Relates to #21

@ankursinha Could you take a look at this pull request
and #30, #32 as well?
There are not a lot of us yet,
but I would still like to move away
from just committing stuff
to a review process.

Sure thing, assigning them all to myself now. Should hopefully have them reviewed before the end of the day.

Metadata Update from @ankursinha:
- Request assigned

2 years ago

This is also covered in the FESCo docs from the looks of it here: https://docs.fedoraproject.org/en-US/fesco/Package_review_policy/#what (paragraph at the end). So perhaps it needs to be linked in this section too, just for clarity.

I think this command is wrong. It needs to be fedpkg request-repo <name of package> <bugid>, no? Only if you're working in a SCM type git repo that's named after the package maybe fedpkg will pick it up, but I don't think newcomers start from such SCM type repos?

Apart from these bits, looks very good. Please feel free to correct and merge :) :thumbsup:

rebased onto 306e0732e9a1f2afdab163dc16a9f10438599460

2 years ago

rebased onto f37c55c

2 years ago

Pull-Request has been merged by oturpe

2 years ago

Thank you for the review!
I fixed the issues you listed,
also still some small formatting improvements.
Merged.