Bug#681833: developers-reference: please document a package salvaging process
On Mon, Jul 16, 2012 at 06:35:33PM -0400, Michael Gilbert wrote:
> I've prepared an initial draft of a developers reference patch that
> would document a package salvaging process. Please see below.
Hi Mike,
I'm not convinced that we need an additional procedure for package salvaging
because we already have procedures addressing that. I suggest that you propose
improvements to the existing procedures if you want them improved. I also
doubt that some things you propose are improvements. I comment in detail on
your patch:
> +<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
Anyone interested can prevent such bit-rot via NMU.
http://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu
> and bug reports go unanswered.
Anyone interested can answer bug reports.
> +Fortunately the NMU process provides a means to inject much needed health into
> +these neglected packages.
Yes, the NMU procedure already addresses that.
> This is the liberal NMU.
If you want the NMU procedure to allow more "liberal" changes then I suggest
that you propose a change to the NMU procedure:
http://www.debian.org/doc/manuals/developers-reference/pkgs.html#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 maintainer has no time to answer the bug report, then anyone interested
can answer the bug report and/or update the package via NMU.
> If the fix is good, it should certainly go into
> +the archive.
Not without permission from the active maintainer. The NMU procedure allows
the active maintainer to object against the NMU.
> 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,
The NMU procedure already mentiones delays and also the use of the DELAYED
queues.
You seem to propose that anyone can just go ahead with uploading NMUs in
DELAYED/10 for fixing lower severity bug reports ignored by an active
maintainer. I object against that.
> and conflicts can be refered to the technical committee as a
> +technical dispute.
> +</para>
This is obviously already described elsewhere.
> +
> +<para>
> +Ideally, the liberal NMU is done by uploading the package of interest to the
> +DELAYED/10 queue or greater.
> +</para>
So far your term "liberal NMU" seems to mean "any fix anyone feels as a good
fix". If your proposal would be that "anything goes via DELAYED/10 queue or
greater", then I would absolutely object against that.
If you want to describe in more detail when the DELAYED/10 queue can be used
for NMU's, then I suggest that you propose changes to the NMU procedure.
> +
> +<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>
You seem to propose a change to what is allowed via NMU. Such changes clearly
belong in the text of the NMU procedure, not in a separate text.
> +
> +<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>
The NMU procedure describes that "you must send a patch with the differences
between the current package and your proposed NMU to the BTS".
A VCS link is, in my opinion, not preferred. If the maintainer no longer
maintains the package, then we already have this procedure:
http://www.debian.org/doc/manuals/developers-reference/beyond-pkging.html#mia-qa
And you seem to repeat that a "liberal NMU" can go in the DELAYED/10 queue.
> +
> +<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.
That is already part of the NMU procedure.
> Failing that, please refer the matter as a
> +technical disagreement to the technical committee.
> +</para>
That is already documented elsewhere.
> +
> +<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.
Sounds like just a friendly package maintenance handover or just adding a
co-maintainer.
If you mean that the current maintainer is forced to step down, then this
procedure applies:
http://www.debian.org/doc/manuals/developers-reference/beyond-pkging.html#mia-qa
If you want the MIA procedure improved, then I suggest that you propose changes
to that.
> 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.
So you propose to ignore the MIA procedure and to go directly to the tech
committee. Has the tech committee taken over the MIA procedure ?
> 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>
The maintainer can simply refuse further NMU's. I don't see any reason to
challenge the maintainer's position before the tech committee in this context.
> +
> +<para>
> +If a package has been already been orphaned, you may salvage it without any
> +kind of approval.
> +</para>
This is already documented in the part about adopting orphaned packages.
> +
> +<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>
You seem to want to prevent hijacking a package via removal and reintroduction.
I don't see how that could be possible, because ftpmaster doesn't remove
packages without good reason.
Also, some packages must be removed asap, for example when the software is
undistributable. After that removal, if the copyright and license issues are
solved, then the software can be reintroduced by anyone interested via an ITP.
I see no problem with that.
Regards,
Bart Martens
Reply to: