Package: developers-reference
Version: 3.4.8
Severity: wishlist
Tags: patch
On Mon, Jul 02, 2012 at 09:55:23AM -0600, Stefano Zacchiroli wrote:
> On Thu, Jun 28, 2012 at 04:42:10PM +0200, Guus Sliepen wrote:
> > I believe our current way of responding to ITPs for software that
> > duplicates the functionality other software that is already in Debian
> > is wrong.>
[...]
> Guus, after having collected feedback from this thread, could you please
> propose a patch to devref for documenting the outcome of this
> discussion?
Sure. Attached is a patch against the developers-reference source. It can
probably be improved, any comments are welcome.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <guus@debian.org>
diff --git a/beyond-pkging.dbk b/beyond-pkging.dbk index 371fba2..5205222 100644 --- a/beyond-pkging.dbk +++ b/beyond-pkging.dbk @@ -569,6 +569,40 @@ for Application Managers</ulink> at the Debian web site. </para> </section> +<section id="reviewing-itp-bug-reports"> +<title>Reviewing ITP bug report</title> +<para> +Prospective Debian developers usually start contributing by creating a new package. +Their first publicly visible act will therefore likely be sending an ITP bug report with a Cc: to the debian-devel mailinglist. +Often there are some issues with the ITP, and these issues should be pointed out to the new maintainer. +However, your response to the ITP should be constructive. +Before responding, consider the following things: +</para> +<itemizedlist> +<listitem> +<para>You don't always have to respond back with a Cc: to debian-devel. Consequently, another developer might already have responded with a message to the BTS, so check the BTS first to see whether what you want to say has already been said. +</para> +</listitem> +<listitem> +<para>If you dislike the software the new maintainer wants to package, +you probably shouldn't complain about this to the maintainer, they are merely packaging it. Complain to upstream instead. +</para> +</listitem> +<listitem> +<para>If you think the software is functionally equivalent to an already packaged piece of software, +don't complain unless: +</para> +<itemizedlist> +<listitem>The new software is not mature or in a bad shape.</listitem> +<listitem>It's a simple script or very small program, and should be merged (either upstream or downstream) with another package.</listitem> +<listitem>It really is an exact duplicate or a fork of another package with almost no changes to the original.</listitem> +</itemizedlist> +<para>Otherwise, it is best to let the new maintainer devote their energy to packaging. +</para> +</listitem> +</itemizedlist> +</section> + </section> </chapter> diff --git a/pkgs.dbk b/pkgs.dbk index 3ce0bee..4d09cc0 100644 --- a/pkgs.dbk +++ b/pkgs.dbk @@ -20,12 +20,27 @@ duplicated. Read the <ulink url="&url-wnpp;">WNPP web pages</ulink> for more information. </para> <para> +You should also consider if your prospective package is suitable for inclusion +in Debian. The software must of course be legally redistributable, and if you +want it to be included in the main section, its license must be compatible with +the DFSG. The software should be useful to others, and should be free of major +bugs (if the software is at version 0.1-alpha, consider waiting with packaging +until it is more mature). If the software you want to package is similar to +that of already packaged software, you should be able to motivate why your +package should be added as well (for example, by providing a list of features +that your package will have that the existing ones don't). If the software +only consists of a very small executable or script, consider getting that +included in an already existing package, if that makes sense, either in Debian +itself or in the upstream source. +</para> +<para> Assuming no one else is already working on your prospective package, you must then submit a bug report (<xref linkend="submit-bug"/>) against the pseudo-package <systemitem role="package">wnpp</systemitem> describing your plan to create a new package, including, but not limiting yourself to, a -description of the package, the license of the prospective package, and the -current URL where it can be downloaded from. +description of the package, the license of the prospective package, the +current URL where it can be downloaded from, and if necessary a motivation +why the package should be included in Debian. </para> <para> You should set the subject of the bug to <literal>ITP:
Attachment:
signature.asc
Description: Digital signature