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 g...@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
+titleReviewing 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
+paraYou 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
+paraIf 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
+paraIf you think the software is functionally equivalent to an already packaged piece of software,
+don't complain unless:
+/para
+itemizedlist
+listitemThe new software is not mature or in a bad shape./listitem
+listitemIt's a simple script or very small program, and should be merged (either upstream or downstream) with another package./listitem
+listitemIt really is an exact duplicate or a fork of another package with almost no changes to the original./listitem
+/itemizedlist
+paraOtherwise, 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=packagewnpp/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 literalITP:
signature.asc
Description: Digital signature
