fesco / fesco-docs

Clone
Source Code
GIT

#15 Update nonresponsive-maintainer policy
Merged 4 years ago by zbyszek. Opened 4 years ago by zbyszek.
nonresp-maintainer-policy  into  master

file modified
+34 -21 
@@ -10,46 +10,60 @@ 
 

  [[coverage]]
 

  == Coverage
 

  

- This policy covers existing Fedora packages; for non-responsive package submitters or reviewers, see the link:https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews[Policy for stalled package reviews]. This mechanism is not limited to existing Fedora contributors. For non-contributors, see below for instructions.
 

+ This policy covers existing Fedora packages, containers, and modules; for non-responsive package submitters or reviewers, see the link:https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews[Policy for stalled package reviews].
 

+ If you are a *not* an existing Fedora contributor, you can follow this procedure too.
 

+ If you want to take over maintainership, you must find a sponsor following the rules specified in
 

+ link:https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group[How to get sponsored into the packager group].
 

  

- The policy is targeted at maintainers that can still be reached through the mail they have registered in fedora. If the mail of the maintainer has changed in a way that seems permanent, and cannot be contacted (with reasonable effort), this policy also applies. If there is no known way of contacting the former maintainer, or they are not willing to make the required change in the packagedb, one can short-circuit the normal 3 week interval required in the Outline steps 1 to 3, and make the formal request to orphan mentioned in step 4.
 

+ [[steps]]
 

+ == Steps
 

  

- [[outline]]
 

- == Outline
 

+ When a Fedora member notices that a maintainer isn't answering their bugs, not answering rebuild requests, link:https://src.fedoraproject.org[src.fedoraproject.org] pull requests, emails, or the like, these steps should be followed:
 

  

- When a Fedora member notices that a maintainer isn't answering their bugs, not answering rebuild requests, src.fedoraproject.org pull requests, emails or the like, these steps should be followed:
 

+ **Week 0**
 

  

- .  Check if the non-responsive maintainer is on link:https://fedoraproject.org/wiki/Vacation[vacation]. To see if the maintainer has been recently active on Fedora, link:https://github.com/pypingou/fedora-active-user[fedora-active-user] can be employed.
 

- .  File a bug against the package in link:https://bugzilla.redhat.com/[Bugzilla] asking for the maintainer to respond. This bug should list the outstanding issues they need to address. This is a *must*.
 

- .  After every 7 days, the reporter adds a comment to the bug report asking again for a response. Others can add to the bug that they also were not successful in contacting the maintainer, or providing additional contact information for the maintainer (i.e., alternative email, IRC, etc).
 

- .  After 2 failed attempts (2 weeks of no response from the maintainer), the reporter posts to the Fedora link:https://admin.fedoraproject.org/mailman/listinfo/devel[devel list] with a link to the bug report and asks if anyone knows how to contact the maintainer.
 

- .  After other 7 days (now 3 weeks total), the reporter creates a link:https://pagure.io/fesco/new_issue[FESCo issue] with the bug link, indicating all reasonable efforts to contact the maintainer have failed and that they wish to take over the package.
 

- .  If at least one FESCo member approves the takeover, and no one objects within 3 days, the reporter may take over the package.
 

- .  Once approval has been given, follow link:https://fedoraproject.org/wiki/PackageDB_admin_requests[PackageDB admin requests] to request ownership of the package. In addition to this, the new owner must also reassign all open bugs for this package to themselves.
 

+ [start=1]
 

+ 1. Check if the non-responsive maintainer is on link:https://apps.fedoraproject.org/calendar/list/vacation/[vacation]. To see if the maintainer has been recently active on Fedora, link:https://github.com/pypingou/fedora-active-user[fedora-active-user] can be employed.
 

+ 2. File a new bug against the package in Bugzilla asking for the maintainer to respond using an appropriate template and fill in all the fields (template for link:https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&format=fedora-nonresponsive-maintainer[nonresponsive package maintainer], link:https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora+Container+Images&format=fedora-nonresponsive-maintainer[nonresponsive container maintainer], or link:https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora+Modules&format=fedora-nonresponsive-maintainer[nonresponsive module maintainer]). This is a *must*.
 

+ 3. Post to the Fedora link:https://admin.fedoraproject.org/mailman/listinfo/devel[devel list] with a link to the bug report and ask if anyone knows how to contact the maintainer. CC the maintainer. Links to all other bug reports open on all neglected packages from the same maintainer *should* be included.
 

  

- If you are a not an existing Fedora contributor, you can still take over a package. All of the above *must* be followed. When you seek approval for the takeover, you, again, *must* provide a Bugzilla report as if it were a new Fedora package review. This will allow the normal review process to happen -- that includes finding a sponsor that believes you understand the packaging rules. Information on sponsorship is at link:https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group[How to get sponsored into the packager group] and the full process for becoming a contributor to Fedora is at link:https://fedoraproject.org/wiki/Join_the_package_collection_maintainers[Join the package collection maintainers]. You'll probably want to start from link:https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_Your_Review_Request[creating your review request]. You can peruse the link:https://fedoraproject.org/wiki/Packaging:Guidelines[packaging guidelines].
 

+ **Week 1**
 

  

- == Notes for mass orphaning
 

+ [start=4]
 

+ 4. After 7 days, submit a link:https://pagure.io/fesco/new_issue/?template=nonresponsive-maintainer&title=Nonresponsive%20maintainer:%20%3Cname%3E%20%3Cfas-id%3E[FESCo issue] with the bug link and mailing list post link. State if you are a packager and want to take over the package. The non-responsive maintainer and all existing maintainers must be @-mentioned in the ticket.
 

+ 5. If at least one FESCo member votes +1 and no one votes differently, the ticket is approved after three days. Otherwise, FESCo will discuss the issue during a meeting.
 

+ 6. If approved, and the reporter is a current Fedora packager in good standing, interested in comaintaining the package, FESCo will default to adding the reporter as the package admin. If the existing co-maintainers of the package do not want the package to be reassigned to the reporter, they should state so in the ticket. If assigned ownership, the reporter can now perform any required package maintenance.
 

  

- * It is common for a Fedora contributor to maintain multiple packages within Fedora, and the situation may arise where multiple packages with a single maintainer need to be orphaned. Given that, it would be quite impractical to create a Bugzilla ticket for each package. In the case where a mass orphaning is likely, the above should still be followed by choosing a single package owned by the potential non-responsive developer. However, the formal request to the Fedora development mailing list should include all other bug reports open on all neglected packages from the same maintainer, indicating that the maintainer is indeed non-responsive. The Steering Committee can then step in and orphan the other packages if necessary.
 

+ **Week 2**
 

+ 

+ [start=7]
 

+ 7. A week later FESCo posts a reminder in the ticket, @-mentioning the maintainer.
 

+ 

+ **Week 3**
 

+ 

+ [start=8]
 

+ 8. With no further reply for the original owner, FESCo closes its ticket and the bugzilla ticket. If maintainership was requested in 4., the reporter will be assigned as the main maintainer of the package, and the package will be orphaned otherwise. All other packages are orphaned too, and may be picked up by co-maintainers or other packagers.
 

+ 

+ Once the final reassignment happens, the new owner must also reassign all open bugs for this package to themselves.
 

  

  [[notes-for-maintainers]]
 

  == Notes for maintainers
 

  

  It is understood that maintainers will go on vacation or will otherwise be unavailable for possibly significant lengths of time. There are a couple of things that maintainers should consider doing if they know in advance that they will be unavailable;
 

  

- * Designate a co-maintainer. Currently there is no policy on the exact details of this, but, in general, another Fedora contributor can be asked to maintain the package in the maintainer's absence. To add a co-maintainer, have the co-maintainer request commit rights in the link:https://admin.fedoraproject.org/pkgdb/[Package Database] and approve the request.
 

+ * Designate a co-maintainer. In general, it is better for every package to have multiple maintainers. Co-maintainers may be added in the Settings tab of the package in link:https://src.fedoraproject.org/[dist-git].
 

  

  * Edit the Vacation page to indicate when you will be away.
 

  

  [[notes-for-invalid-email-addresses]]
 

  == Notes for invalid email addresses
 

  

- bugzilla.redhat.com uses the email address in the Fedora Account System to send messages to the package maintainer. If it becomes known that this email address no longer goes to the package maintainer the policy may be short-circuited. Start with Step #4 in the Outline. If the maintainer hasn't become responsive at the end of that process FESCo will mass orphan all packages they own.
 

+ link:https://bugzilla.redhat.com[Bugzilla] uses the email address in the Fedora Account System to send messages to the package maintainer.
 

+ If it becomes known that this email address no longer goes to the package maintainer, this should be noted in the mailing list post and FESCo ticket, but the policy outline above will still be followed.
 

  

  Situations where it becomes known that an email address is no longer going to go to the maintainer are:
 

  

- .  Email to the address bounces (to differentiate from temporary bounces like a mailbox full, this should go on for a period of 7 days)
 

+ .  Email to the address bounces (to differentiate from temporary bounces like a mailbox full, this should go on for a period of 7 days).
 

  .  Red Hat lets us know that an email address is no longer valid for the package maintainer (usually because the person has left Red Hat).
 

  

  [[exception-procedure]]
 
@@ -65,12 +79,11 @@ 
 

  Steps:
 

  

  .  Explain why the exception process is needed and note all communication attempts in an email to the devel@lists.fedoraproject.org list with the non-responsive maintainer CC'ed on the email.
 

- .  Mention and maintainers FAS account (after an '`@`' sign) and describe the situation in a new ticket with the 'meeting' label to notify FESCo to discuss the situation during the next xref:index.adoc#_meetings[meeting].
 

- .  The next FESCo meeting will discuss the case and reach a decision.
 

+ .  Open the FESCo ticket described in step 4 without waiting a week and also describe the situation there.
 

  

  [[orphaning-process]]
 

  == Orphaning process
 

  

  Unless there is a reason not to (the maintainer's email is bouncing, the maintainer has told someone that they are not interested in continuing to maintain Fedora packages) we will make the maintainer a comaintainer on the package in all branches they were an owner. Then we will orphan the packages.
 

  

- If the maintainer's email is bouncing or we've been told that the maintainer is not interested in continuing to contribute to Fedora we'll remove all of the maintainer's acls from the pkgdb.
 

+ If the maintainer's email is bouncing or we've been told that the maintainer is not interested in continuing to contribute to Fedora we'll remove all of the maintainer's acls.

https://pagure.io/fesco/issue/2149

Outstanding issues:

  1. I couldn't find a way to get the numbering correct after splitting the list with subheaders.
    Antora warns when the list is restarted with numbers above 1, and ignores them.
    Asciidoctor docs specify that [start=n] may be used, but that has no effect whatsover.
    Stefano[m] suggested using + to concatenate the subheader to previous list item. This works, but breaks alignment of the subheaders.

  2. I made some additional changes to earlier and later parts of the text to make them consistent with the changed part. I think this doesn't change things materially, but PTAL.

  3. Bugzilla template needs to be created at https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&format=fedora-nonresponsive-maintainer

  4. I created a fesco issue template. It can be selected from a drop-down list, but I didn't see a way to link to it so it is preselected, like in bugzilla. I also didn't see a way to pre-fill the issue title, like in bugzilla.

rebased onto 884b92e
4 years ago

I added a second commit to kill references to pkdb and to add recommendation to have multiple maintainers.

@zbyszek Regarding the list, I played around with it and it doesn't seem possible to do this without misaligning the titles. In theory asciidoc supports [start=X] to start an ordered list from a number other than 1 (https://asciidoctor.org/docs/user-manual/#ordered-lists), but Antora seems to ignore that, either due to a bug or maybe it's just not implemented yet. I opened an issue for Antora about this (https://gitlab.com/antora/antora/issues/441).

I think the best course of action is to just treat each week as a separate list and start it from 1 - I don't think it hurts readability too much.

Also a style note, you might want to use discrete headings instead of bold text. Discrete means it won't show in the ToC and won't create an anchor but it will be styled as a heading. Like this:

[discrete]
=== Week 0

. item one

@pbokoc thanks for looking into this. Upstream issue is closed. Is this a matter of upgrading something in Fedora?

1 new commit added

  • Add [start=n] annotations after all
4 years ago

Ah, yeah, we should update our UI then. The person responsible for that is away till July 20 so the fix should happen sometime after that - I'll let him know.

FESCo issue (using the nonresponsive-maintainer template)

I created a fesco issue template. It can be selected from a drop-down list, but I didn't see a way to link to it so it is preselected, like in bugzilla. I also didn't see a way to pre-fill the issue title, like in bugzilla.

Tagging @pingou here in case he has ideas.

I created a fesco issue template. It can be selected from a drop-down list, but I didn't see a way to link to it so it is preselected, like in bugzilla.

https://docs.pagure.org/pagure/usage/tips_tricks.html#pre-fill-issue-template-using-the-url

I also didn't see a way to pre-fill the issue title, like in bugzilla.

https://docs.pagure.org/pagure/usage/tips_tricks.html#pre-fill-issue-using-the-url

Should be:

https://pagure.io/fesco/new_issue/?template=nonresponsive-maintainer&title=Nonresponsive%20maintainer:%20%3Cname%3E%20%3Cfas-id%3E

Thanks @pingou

@zbyszek There is a typo in the template: Nonreponsive should be Nonresponsive (figured that out when copy pasting it to the URL) - but that line can go away now when we have a title.

1 new commit added

  • Update link to nonresponsive-matainer template
4 years ago

@pingou, @churchyard, thanks!

Can somebody with the right privs create the bugzilla template?
( Target URL is https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&format=fedora-nonresponsive-maintainer, and the text is in https://pagure.io/fesco/issue/2149#comment-579981, around the middle. )

 
package: <package>, <link-to-open-bug>
nonresponsive maintainer bug: <link-to-nonresponsive-maintainer-bug>

What exactly is <link-to-open-bug> supposed to link to if not <link-to-nonresponsive-maintainer-bug>?

IIUC, there are always at least two bugs in play: some original bug or bugs open against the package, and then the nonresponsive-maintainer bug created in step 2 ("create new bug").

Sometimes it is a PR, sometimes it is a bug, nevertheless here it will be confusing. What about we either not have it in the template, or we change it to:

package: <package>
issues to fix: <links-to-open-bugs>
nonresponsive maintainer bug: <link-to-nonresponsive-maintainer-bug>

Updated in the fesco template.

LGTM

I've e-mailed bugzilla-requests@redhat.com with the template request.

I was redirected to bugzilla and created https://bugzilla.redhat.com/show_bug.cgi?id=1731835

2 UX issues with the fesco issue template:

  • make the sections bold (as in package: foo)
  • add room for mentioning the maintainer

Pushed the above.

Fesco, please see https://bugzilla.redhat.com/show_bug.cgi?id=1731835#c1
- there are some possible alternatives to the bugzilla template (such as using URL fields).

1 new commit added

  • Add separate links for packages, modules, and containers
4 years ago

Pull-Request has been merged by zbyszek
4 years ago

\o/

Yeah, but the online text is not updating. I don't want to send the announcement before that happens :(

Yeah, but the online text is not updating. I don't want to send the announcement before that happens :(

I asked about that before. It updates every couple hours. It looks to be up to date now.
Metadata
None
No Tags
Changes Summary 1
+34 -21
file changed
fesco/modules/ROOT/pages/Policy_for_nonresponsive_package_maintainers.adoc
Powered by Pagure 5.13.3
Documentation • File an Issue • About • SSH Hostkey/Fingerprint
© Red Hat, Inc. and others.