#307 Update EPEL package request to add clarity for existing maintainers and releng
Opened 3 months ago by salimma. Modified 3 months ago
salimma/epel epel-request-tweaks  into  main

@@ -79,6 +79,8 @@ 

  

  ....

  Please branch and build <package> in epel9.

+ 

+ Please refer to https://docs.fedoraproject.org/en-US/epel/epel-package-request/#existing_maintainers for additional details.

  ....

  

  If there is no response after a week, add the following comment in the bug.
@@ -102,6 +104,11 @@ 

  or do not think you will be able to do this in a timely manner,

  I would be happy to be a co-maintainer of the package (FAS <your FAS Id>);

  please add me through https://src.fedoraproject.org/rpms/<package>/adduser

+ 

+ (optionally, if there's not a separate Bugzilla assignee for EPEL)

I don't think we should make this part optional. More specifically, it should be mandatory that the requestor using this template is willing to be the EPEL default bugzilla assignee, but it's optional for the maintainer to actually set it to that.

+ I can be the primary contact for EPEL (FAS: <my_FAS_id>).

+ 

+ Please refer to https://docs.fedoraproject.org/en-US/epel/epel-package-request/#existing_maintainers for additional details.

  ....

  

  If there is no response after a week, add the following comment in the bug.
@@ -123,6 +130,7 @@ 

  Per the EPEL stalled package policy - https://docs.fedoraproject.org/en-US/epel/epel-policy/#stalled_epel_requests - I have contacted the maintainer, twice, and waited the appropriate amount of time.

  <Bugzilla URL>

  I am requesting <my_FAS_id> be given commit permissions so that I might branch and build this package in epel9.

+ Please refer to https://docs.fedoraproject.org/en-US/epel/epel-package-request/#releng for additional details.

  

  <Fill out the other sections as you see fit>

  ....
@@ -132,6 +140,13 @@ 

  [[epel_packagers_sig_members]]

  === EPEL Packagers SIG members

  

+ [NOTE]

+ .EPEL Packagers SIG under review

+ ====

+ The working of this SIG is currently being reviewed. Please hold off

+ requesting access via the SIG until this is resolved.

+ ====

I worry that a note will be too easy to be missed by someone coming to this page just to copy the template. I think we should just remove the SIG template entirely. We can always add it back if we decide to keep the SIG, but in the meantime removing the template will prevent anyone from copying the text from here.

+ 

  Clear out Description and put

  

  ....
@@ -145,10 +160,13 @@ 

  and grant it commit access, or collaborator access on epel* branches.

  

  (optionally, to request access for yourself)

- I would also be happy to be a co-maintainer (FAS: <my_FAS_id>).

+ I would also be happy to be a co-maintainer (FAS: <my_FAS_id>);

+ please add me through https://src.fedoraproject.org/rpms/<package>/adduser

  

  (optionally, if there's not a separate Bugzilla assignee for EPEL)

  I can be the primary contact for EPEL (FAS: <my_FAS_id>).

+ 

+ Please refer to https://docs.fedoraproject.org/en-US/epel/epel-package-request/#existing_maintainers for additional details.

  ....

  

  If there is no response after a week, add the following comment in the bug.
@@ -170,8 +188,48 @@ 

  Per the EPEL stalled package policy - https://docs.fedoraproject.org/en-US/epel/epel-policy/#stalled_epel_requests - I have contacted the maintainer, twice, and waited the appropriate amount of time.

  <Bugzilla URL>

  I am a member of the epel-packagers-sig and I am requesting epel-packagers-sig be given commit permissions so that I, or a member of the SIG, might branch and build this package in epel9. Please also add my account: <my_FAS_id>.

+ Please refer to https://docs.fedoraproject.org/en-US/epel/epel-package-request/#releng for additional details.

  

  <Fill out the other sections as you see fit>

  ....

  

  After the epel-packagers-sig has been given commit permissions, you can then branch, build, and maintain the package in epel.

+ 

+ [[handling_epel_requests]]

+ == Handling EPEL package requests

+ [[existing_maintainers]]

+ === For package maintainers

+ 

+ If you would like to handle a branch and build request yourself, see the https://docs.fedoraproject.org/en-US/package-maintainers/Package_Maintenance_Guide/#working_with_branches[working with branches] section of the Package Maintenance Guide.

+ 

+ If the requester volunteers to co-maintain the package, any existing

+ comaintainer with admin access can add them via

+ https://src.fedoraproject.org/rpms/<package>/adduser .

+ 

+ Similarly, to add a packager group to the package, use

+ https://src.fedoraproject.org/rpms/<package>/addgroup .

+ 

+ Do note that

+ - if you grant commit access, the grantee can also commit to Fedora branches

+ - if you grant collaborator access, the grant needs to be to `epel*` to

+   future proof this for future releases

+ 

+ If the existing comaintainers do not want to maintain the package in EPEL

+ at all, the person or group mentioned in the request can be made the

+ Bugzilla assignee for that package. Note that only the main admin can set this.

+ 

+ Do check with https://docs.fedoraproject.org/en-US/fesco/SIG_policy/[SIG policy]

+ to see if the mentioned SIG has a policy for co-maintaining packages or not.

+ 

+ [[releng]]

+ === For releng

+ When handling a xref:epel-policy.adoc#stalled_epel_requests[Stalled EPEL Request]

+ 

+ - make sure that due process has been observed (bug filed, ping after a week,

+   and at least two weeks since the ping)

+ - if the the request is to add both a person and a group to the package, make

+   sure to add both

+ 

+ For packages that have collaborator access set to anything other than `epel*`,

+ someone who is a collaborator directly or indirectly via group membership may

+ file a ticket to ask releng to set this to `epel*`.

I think (but please test) admins of the package can change this...

Yes, package admins can set this, but the problem we've seen a few times is the package admin sets it to a specific branch like epel9 instead of epel*, then the collaborator can't request an epel10 branch. I think the goal here is to make it policy that releng can adjust the permission to a wildcard if it was set incorrectly, without waiting on the package admin to do it.

For consistency in handling EPEL package requests, document needed steps
for existing maintainers and for releng.

Also make the request templates more consistent between regular
packagers and EPEL Packagers SIG members.

Finally, put an advisory note to not request access via the SIG route
for now while the workings are being reviewed.

Signed-off-by: Michel Lind salimma@fedoraproject.org

rebased onto 557fcfc

3 months ago

I think (but please test) admins of the package can change this...

Could we add a note for before filing the bug/request to suggest trying to scratch build the latest fedora rawhide version of the package and note missing deps? This would save time when you request something, wait for the maintainer, they check and see they need 10 things and then you have to wait for those too. I'm not sure the best solution here, but I think it would help if the requestor is able to do at least a first level pass...

I don't think we should make this part optional. More specifically, it should be mandatory that the requestor using this template is willing to be the EPEL default bugzilla assignee, but it's optional for the maintainer to actually set it to that.

I worry that a note will be too easy to be missed by someone coming to this page just to copy the template. I think we should just remove the SIG template entirely. We can always add it back if we decide to keep the SIG, but in the meantime removing the template will prevent anyone from copying the text from here.

Yes, package admins can set this, but the problem we've seen a few times is the package admin sets it to a specific branch like epel9 instead of epel*, then the collaborator can't request an epel10 branch. I think the goal here is to make it policy that releng can adjust the permission to a wildcard if it was set incorrectly, without waiting on the package admin to do it.

Thanks for the feedback all. I'll take another pass - probably won't have time today but likely tomorrow or Friday

Also to note: FESCo is thinking of adopting this but making the timeline more aggressive, but I think it's still worth revising our document as the FESCo process revision will likely take a bit longer

Metadata