From Fedora Project Wiki

(case)
(Exception procedure: update for pagure and re-word)
(15 intermediate revisions by 7 users not shown)
Line 1: Line 1:
[[Category:Policy]]
 
<!-- page was renamed from PackageMaintainers/Policy/AWOL Maintainers
 
-->
 
<!-- page was renamed from Extras/Policy/AWOL Maintainers
 
-->
 
 
= Non-responsive Maintainer Policy =
 
= Non-responsive Maintainer Policy =
 
== Digest ==
 
 
<!-- INCLUDEPOLICYFRONTSTART
 
-->
 
<onlyinclude>
 
 
* File a bug against the package in bugzilla asking for the maintainer to respond (after checking if the maintainer is on [[Vacation]] ).
 
* After every 7 days, the reporter adds a comment to the bug report for each unsuccessful attempt to contact.
 
* After 2 attempts of no contact, the reporter asks if anyone knows how to contact the maintainer.
 
* After another 7 days, the reporter posts a formal request to the fedora-devel list with the bug link.
 
* If at least one FESco member approves the takeover and no one objects within 3 days, the requester may take over the package. If the requester is a not an existing Fedora contributor, they may still take over the package. Once approval has been given, follow [[PackageMaintainers/CVSAdminProcedure]]  to have ownership of the package changed. In addition to this, the new owner must also reassign any open bugs on that package to themselves.
 
 
</onlyinclude>
 
<!-- INCLUDEPOLICYFRONTEND
 
-->
 
 
{{Anchor|afterinclude}}
 
  
 
== Purpose ==
 
== Purpose ==
Line 30: Line 7:
 
== Coverage ==
 
== Coverage ==
  
This policy covers existing Fedora packages; for non-responsive package submitters or reviewers, see [[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; for non-responsive package submitters or reviewers, see the [[Policy for stalled package reviews]]. This mechanism is not limited to existing Fedora contributors. For non-contributors, see below for instructions.
  
 
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.
 
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.
Line 36: Line 13:
 
== Outline ==
 
== Outline ==
  
* When a Fedora member notices that a maintainer isn't answering their bugs, not answering rebuild requests, emails or the like, they need to file a bug against the package in bugzilla asking for the maintainer to respond. This bug should list the outstanding issues they need to address. This is a '''must'''. '''Note''': Be sure to check the [[Vacation]] page before opening the bug, to verify that the maintainer is not away on vacation.
+
When a Fedora member notices that a maintainer isn't answering their bugs, not answering rebuild requests, emails or the like, these steps should be followed:
 +
<!-- INCLUDEPOLICYFRONTSTART
 +
-->
 +
<onlyinclude>
 +
# Check if the non-responsive maintainer is on [[Vacation|vacation]]. To see if the maintainer has been recently active on Fedora, [https://github.com/pypingou/fedora-active-user fedora-active-user] can be employed.
 +
# File a bug against the package in [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 [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 [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 [[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.
 +
</onlyinclude>
 +
<!-- INCLUDEPOLICYFRONTEND
 +
-->
  
* After every 7 days, the reporter adds a comment to the bug 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 (ie, alternative email, irc, etc).
+
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 [[How_to_get_sponsored_into_the_packager_group]] and the full process for becoming a contributor to Fedora is at [[Join the package collection maintainers]]. You'll probably want to start from [[Join the package collection maintainers#Create_Your_Review_Request|creating your review request]]. You can peruse the [[Packaging:Guidelines|packaging guidelines]].
  
* After 2 attempts (2 weeks) of no response from the maintainer, the reporter posts to the fedora-devel list with a url to the bug report and asks if anyone knows how to contact the maintainer.
+
== Notes for Mass Orphaning ==
  
* After another 7 days (now 3 weeks total), the reporter posts a formal request to the fedora-devel list with the bug link, indicating all reasonable efforts have been made to contact the maintainer have failed and that they wish to take over the package.
+
* 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 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.
  
* If at least one FESco member approves the takeover, and no one objects within 3 days, you may take over the package.
+
== Notes for maintainers ==
  
* 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 [[PackageMaintainers/HowToGetSponsored]]  and the full process for becoming a contributor to Fedora is at [[PackageMaintainers/Join]].  You'll probably want to start from [[PackageMaintainers/Join#Create_Your_Review_Request|step 7]].  You can peruse the packaging guidelines at [[Packaging/Guidelines]].
+
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;
  
* Once approval has been given, follow [[PackageMaintainers/CVSAdminProcedure]]  to have ownership of the package changed. In addition to this, the new owner must also reassign any open bugs on that package to themselves.
+
* 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 absense. To add a co-maintainer, have the co-maintainer request commit rights in the [https://admin.fedoraproject.org/pkgdb/ Package Database] and approve the request.
  
== Notes for Mass Orphaning ==
+
* Edit the [[Vacation]]  page to indicate when you will be away.
  
* 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 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.
+
== Notes for invalid email addresses ==
  
== Notes for Maintainers ==
+
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.
  
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;
+
Situations where it becomes known that an email address is no longer going to go to the maintainer are:
  
* 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 absense.  To add a co-maintainer, follow the procedure at [[PackageMaintainers/CVSAdminProcedure]]  (this may change soon to use the [https://admin.fedoraproject.org/pkgdb/ PackageDB] ).
+
# Email to the address bounces (to differentiate from temporary bounces like 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).
  
* Edit the [[Vacation]]  page to indicate when you will be away.
+
== Exception procedure ==
  
== Fast Track procedure ==
+
There are some cases where it may be needed to reassign a package even if
 +
this procedure has not yet finished. Examples include when many dependencies
 +
are broken, version updates are needed for security or stability reasons, or
 +
maintainer response prevents the non-responsive process from proceeding
 +
without actually resuming maintenance. In such cases, this exception
 +
procedure can be used.
  
In some cases it may be needed to reassign a package from a non responsive maintainer quickly, for example: when many dependencies are broken by their
+
Steps:  
package, there is a lot of integration work needed, a version update is required for security or stability issues or the maintainer has been
 
non responsive for a long time, but the above procedure has never been completed. In such cases this "fast track" process can be used.
 
  
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 [[Fedora_Engineering_Steering_Committee#Meetings|meeting]].
 +
# The next FESCo meeting will discuss the case and reach a decision.
  
* Write email to fedora-devel list with the non responsive maintainer Cc'ed on the post. Explain why you think the fast track process is needed.
+
== Orphaning Process ==
(Make sure and note any communication attempts done already)
 
  
* Open a ticket in the [https://fedorahosted.org/fesco/newtplticket fesco trac] instance with the maintainers FAS account cc'ed. Add the 'meeting' keyword.  
+
Unless there is 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 owner. Then we will orphan the packages.
  
* The next FESCo meeting will discuss the case and reach a decision.
+
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.
  
 
[[Category:Package Maintainers]]
 
[[Category:Package Maintainers]]
 
[[Category:FESCo policy]]
 
[[Category:FESCo policy]]
 +
[[Category:Policy]]

Revision as of 22:07, 6 September 2017

Non-responsive Maintainer Policy

Purpose

The purpose for this policy is to provide a mechanism within Fedora to handle situations when a package maintainer becomes unavailable to continue maintainership, often referred to as non-responsive. The end goal is to help prevent packages becoming stale through non-maintenance, reduce open bugs on non-maintained packages and assist in the overall quality of Fedora.

Coverage

This policy covers existing Fedora packages; for non-responsive package submitters or reviewers, see the Policy for stalled package reviews. This mechanism is not limited to existing Fedora contributors. For non-contributors, see below for instructions.

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.

Outline

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

  1. Check if the non-responsive maintainer is on vacation. To see if the maintainer has been recently active on Fedora, fedora-active-user can be employed.
  2. File a bug against the package in Bugzilla asking for the maintainer to respond. This bug should list the outstanding issues they need to address. This is a must.
  3. 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).
  4. After 2 failed attempts (2 weeks of no response from the maintainer), the reporter posts to the Fedora devel list with a link to the bug report and asks if anyone knows how to contact the maintainer.
  5. After other 7 days (now 3 weeks total), the reporter creates a 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.
  6. If at least one FESCo member approves the takeover, and no one objects within 3 days, the reporter may take over the package.
  7. Once approval has been given, follow 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.


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 How_to_get_sponsored_into_the_packager_group and the full process for becoming a contributor to Fedora is at Join the package collection maintainers. You'll probably want to start from creating your review request. You can peruse the packaging guidelines.

Notes for Mass Orphaning

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

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 absense. To add a co-maintainer, have the co-maintainer request commit rights in the Package Database and approve the request.
  • Edit the Vacation page to indicate when you will be away.

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.

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

  1. Email to the address bounces (to differentiate from temporary bounces like mailbox full, this should go on for a period of 7 days)
  2. 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

There are some cases where it may be needed to reassign a package even if this procedure has not yet finished. Examples include when many dependencies are broken, version updates are needed for security or stability reasons, or maintainer response prevents the non-responsive process from proceeding without actually resuming maintenance. In such cases, this exception procedure can be used.

Steps:

  1. 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.
  2. 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 meeting.
  3. The next FESCo meeting will discuss the case and reach a decision.

Orphaning Process

Unless there is 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 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.