Please remove this {{Draft}}template, when you're sure the page is complete and correct.
|
There are all sorts of reasons for a package maintainer to cease maintaining a package: it's part of the way that open-source software works. There is no obligation on anyone's part to continue working on something and the reason for becoming unresponsive may well be completely outside the maintainer's control. The end goal of this Policy is to help prevent packages becoming stale through lack of maintenance, reduce open bugs on unmaintained packages and assist in the overall quality of Mageia by defining a way that the lack of maintenance of a package or packages can be overcome. It is not there to punish or compel unresponsive maintainers to continue. They may well be DEAD. It happens. :-(
Contents
Policy for dealing with unresponsive package maintainers
Digest
- File a bug against the package in bugzilla asking for the maintainer to respond (after checking that the maintainer has not logged an absence on the Absence page ).
- After 7 days the reporter adds a comment to the bug report for each unsuccessful attempt to contact.
- After 2 attempts with no contact the reporter asks if anyone knows how to contact the maintainer.
- After a further 7 days the reporter posts a formal request to the dev list with the bug link.
- If at least one packaging team leader/representative/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 Mageia contributor, they may still take over the package. Once approval has been given, send a mail to sysadmin-discuss@ml.mageia.org 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.
Coverage
This policy covers existing Mageia packages. This mechanism is not limited to existing Mageia contributors. For non-contributors, see below for instructions.
The policy is targeted at maintainers that can still be reached through the e-mail address they have registered. If the e-mail address of the maintainer has changed in a way that seems permanent and cannot be contacted (with reasonable effort), then 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 maintdb, 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 Mageia 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 Maintainer's absence page in case the maintainer has recorded an absence before opening the bug.
- After 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 (i.e., alternative email, IRC, etc).
- After 2 attempts (2 weeks) of no response from the maintainer, the reporter posts to the dev mailing list with a URL to the bug report and asks if anyone knows how to contact the maintainer.
- After another 7 days (now 3 weeks total), the reporter posts a formal request to the dev mailing 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.
- If at least one packaging team leader/representative/member approves the takeover, and no one objects within 3 days, you may take over the package.
- If you are a not an existing Mageia 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 Mageia package review. This will allow the normal review process to happen -- that includes finding a mentor. Information on mentorship can be found at Becoming_a_Mageia_Mentor and instructions how to become a Mageia packager can be found at Becoming_a_Mageia_Packager. You should also read the packaging guidelines.
- Once approval has been given, send an e-mail to sysadmin-discuss@ml.mageia.org 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.
Notes for Mass Orphaning
- It is common for a Mageia contributor to maintain multiple packages within Mageia, 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 unresponsive developer. However, the formal request to the dev mailing list should include all other bug reports open on all neglected packages from the same maintainer, indicating that the maintainer is indeed unresponsive. The packaging team leaders/representatives/sysadmins 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 Mageia contributor can be asked to maintain the package in the maintainer's absence.
- Edit the Absence page to indicate when you will be away.
Fast Track procedure
In some cases it may be necessary to reassign a package from an unresponsive maintainer quickly, for example: when many dependencies are broken by their package; a lot of integration work is required; a version update is required for security or stability issues; or perhaps the maintainer has been unresponsive for a long time but the above procedure has never been completed. In such cases this "fast track" process can be used.
Steps:
- Write email to dev mailing list, with a cc: to the non responsive maintainer. Explain why you think the fast track process is needed (remember to note any communication attempts already made).
- Open a ticket in the Fedora Engineering Steering Committee Issue Tracking System, copied to the maintainer's FAS account. Add the 'meeting' keyword.
NOTE: Fedora has a special issue tracking system related to the council or packaging team.
If we decide that we do not, as yet, require such a system, then we should remove the second step. This is up for discussion!
This was imported from Fedora Project wiki licensed under CC-By-SA 3.0
