Bug#681833: developers-reference: please document a package salvaging process
package: developers-reference
severity: normal
version: 3.4.8
tag: patch
Hi,
I've prepared an initial draft of a developers reference patch that
would document a package salvaging process. Please see below.
Best wishes,
Mike
--- pkgs.dbk.orig 2012-07-16 18:19:56.065047490 -0400
+++ pkgs.dbk 2012-07-16 18:32:20.626439544 -0400
@@ -2257,6 +2257,86 @@
</section>
+<section id="package-salvaging">
+<title>Package Salvaging</title>
+
+<para>
+Unfortunately over time, certain maintainers become less active without turning
+over their packages via the orphaning process or fully leaving the project.
+This is a natural process, and there is nothing wrong with it, but in the
+meantime their packages suffer bit-rot and bug reports go unanswered.
+Fortunately the NMU process provides a means to inject much needed health into
+these neglected packages. This is the liberal NMU.
+</para>
+
+<para>
+Also, at times, there can be situations where contributors would like to modify
+a package for a lower severity bug report, but said bug is ignored for a long
+time by an active maintainer. If the fix is good, it should certainly go into
+the archive. This is another case where an NMU is appropriate, but it would
+not be considered a liberal NMU. These cases can be resolved by are a standard
+10-day NMU, and conflicts can be refered to the technical committee as a
+technical dispute.
+</para>
+
+<para>
+Ideally, the liberal NMU is done by uploading the package of interest to the
+DELAYED/10 queue or greater.
+</para>
+
+<para>
+The liberal NMU is also appropriate in general for fixing bugs, but
for packages
+that have not recieved an upload in greater than six months liberal NMUs are
+highly encouraged and can fix issues that are not tracked in the BTS. Changing
+the build system in a Liberal NMU is still not acceptable, but all
other changes
+are allowed including packages of new upstream versions.
+</para>
+
+<para>
+A mail for each Liberal NMU should be sent to either the maintainer or the BTS
+(which is automatically forwarded to the maintainer) and should include a
+hyperlink to a VCS containing the changeset of this liberal NMU and all of your
+prior liberal NMUs to this package. A VCS link is preferred to
+an NMU patch in these cases since long-term if the maintainer does not
+resume activity, you will be making many liberal NMUs and ultimately becoming
+its maintainer. The message body should maintain a positive
+attitude and mention that the maintainer may review and has the option to
+cancel the NMU while it waits in the upload queue for the next 10 or more days.
+</para>
+
+<para>
+Unfortunately the maintainer may reject some of your contributions that you
+disagree with. In this case, try to find a way to implement the changes in a
+way that the maintain will approve. Failing that, please refer the matter as a
+technical disagreement to the technical committee.
+</para>
+
+<para>
+Preferably, after you have demonstrated that you can handle the package, the
+maintainer will either step down or approve you to be a part of the packaging
+team. If the maintainer has been active or not approved this after an
+additional six months after your first liberal NMU, you may petition the tech
+committee to rule on the maintainership of the package. Please include as much
+information as possible (including bug reports, uploaded versions, VCS links,
+etc.) to make the committee's decision easy. If the maintainer at some point
+becomes active, and does not want your participation to continue, you may
+petition either accept that request and step down or petition the tech
+committee to rule on the matter.
+</para>
+
+<para>
+If a package has been already been orphaned, you may salvage it without any
+kind of approval.
+</para>
+
+<para>
+Filing a removal request against ftp.debian.org, then reintroducing the package
+with yourself as the maintainer is considered adversarial and is explicitly
+disallowed.
+</para>
+
+</section>
+
</section>
<section id="collaborative-maint">
Reply to: