[PROPOSAL v2] Orphaning another maintainer's packages
Hi,
According to the huge thread starting at
https://lists.debian.org/debian-devel/2012/10/msg00469.html, it seems that:
- there's consensus that a lightweight process for orphaning unmaintained
packages is a good idea (if you are not convinced yet, I urge you to read
Russ' post at https://lists.debian.org/debian-devel/2012/10/msg00546.html )
- there's consensus on how to initiate the process
- there's some disagreement on how to complete the process:
+ some think waiting for ACKs will not work because not enough people
might care to ACK
+ some would prefer a policy based on "no objection for some time"
+ some think that NACKs should block the process
I think I agree with everybody, so here is a new version of the last step of
the proposed procedure:
----------------------------------->8
4. When/if consensus has been reached, or if no objections have been raised,
the package can be orphaned by retitling and reassigning the ITO bug
accordingly. Here are some example situations where it is considered
acceptable to move forward:
- one month has passed since the ITO bug was submitted, and nobody
objected to the orphaning;
- one week has passed since the ITO bug was submitted, and at least
3 DDs supported the orphaning (possibly including the submitter
of the ITO bug, if it was a DD), while nobody objected.
If someone opposed the orphaning, it is generally a better idea to
forward the issue to the Technical Committee. However, if objections
have been well addressed and there is consensus (indicated by a very
large majority of supporters) in favor of the orphaning, it is still
possible to move forward.
----------------------------------->8
For completeness, here is the full proposal. I've also addressed a few
cosmetic comments.
----------------------------------->8
Orphaning another maintainer's packages
It is not uncommon for some packages to end up in an unclear situation,
with a maintainer without enough time to maintain them properly. The NMU
procedure (described in developers-reference section 5.11) enables other
contributors to fix problems when a maintainer is unavailable,
but maintaining packages through NMUs is not a viable long term
solution, and it is sometimes required to transfer the maintenance of a
package to another contributor.
This section describes the recommended procedure to orphan a package,
thus giving candidate adopters the possibility to take over the
maintenance of a package. This procedure aims at being efficient at
addressing simple and obvious cases. It is not suitable for more
difficult or controversial cases (e.g. active but non-cooperative
maintainer) -- in such cases, the issue should be brought to the
Technical Committee, as described in the Debian Constitution, section
6.1.
1. Someone opens an ITO (Intent to Orphan) bug against the package whose
orphaning is suggested, with the 'serious' severity. The submitter
notifies debian-qa@lists.debian.org (e.g. using X-Debbugs-Cc:
debian-qa@lists.debian.org) of the process.
The bug report should contain a detailed analysis of the state of
the package, explaining why it should be orphaned. The analysis
should focus on the package, not on the maintainer, and great
care should be taken to avoid formulations that would be
offensive for the maintainer.
Relevant information include: release critical bugs, whether
the package blocks progress elsewhere in Debian, history of NMUs,
lack of any recent activity on that package by the maintainer, public
comments of the maintainer showing a lack of interest in the package,
previous attempts to contact the maintainer, etc.
2. The submitter should seek comments from the package maintainer
(e.g., by sending a private mail notifying him/her of the process).
3. Debian Developers can then support or oppose the proposed orphaning (using
signed mails sent to the bug and to debian-qa@lists.debian.org).
Everybody is welcomed to contribute to the discussion, e.g. to comment
on problems experienced by users due to the level of maintenance.
4. When/if consensus has been reached, or if no objections have been raised,
the package can be orphaned by retitling and reassigning the ITO bug
accordingly. Here are some example situations where it is considered
acceptable to move forward:
- one month has passed since the ITO bug was submitted, and nobody
objected to the orphaning;
- one week has passed since the ITO bug was submitted, and at least
3 DDs supported the orphaning (possibly including the submitter
of the ITO bug, if it was a DD), while nobody objected.
If someone opposed the orphaning, it is generally a better idea to
forward the issue to the Technical Committee. However, if objections
have been well addressed and there is consensus (indicated by a very
large majority of supporters) in favor of the orphaning, it is still
possible to move forward.
----------------------------------->8
Comments?
Lucas
Reply to: