debian/rules VS debian/copyright.

March 21st, 2012 - 08:10 pm ET by Mike Mestnik | Report spam

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
boundary="060104030002070008090304"

This is a multi-part message in MIME format.

I'm really a horrible person and I'm excellent at writing files like
debian/rules. From my perspective it's perfectly clear that a simple
tool designed to write perfect debian/rules files would have no chance
at writing a debian/copyright file. I understand that for decades there
has been a large group of hard working individuals that excel at writing
both.

I'd like to point out a need, and a desire on my part, for this to change.

I've been told that in order to write a good debian/copyright one must
have interment knowledge of a package and therefore be part of the
packaging team. I fail to see how the two relate, there is a lot more
that goes into a package then just the debian/copyright and unlike the
debian/rules it stands alone as it doesnt interface with any other part
of the Debian Package, excepting that the original source is not part of
the Debian Package(at least in this instance).

Both files interface with the original source, but that's where the
similarities end.

I've also been told that having a single maintainer responsible for the
package as a whole is a good idea. I say one can easily split technical
and legal responsibility without the need for any gray lines. Doing so
reduces the knowledge base, an important part of finding the right ppl.
Allowing for more knowledgeable technical writers, like myself, to write
excellent packages and debian/rules files further improving the quality
of Debian.

1. I see a clear benefit.
2. I see a long road ahead.
3. I see an eventual finish where Package Maintainers and Helpers can
either focus on debian/rules or debian/copyright without the need to be
familiar at all with the other.

I offer up this edit for your review. I understand many might hate and
oppose the idea of splitting the two.

Thank you.

name="my_patch.txt"
filename="my_patch.txt"

Index: english/intro/help.wml
=
RCS file: /cvs/webwml/webwml/english/intro/help.wml,v
retrieving revision 1.11
diff -u -r1.11 help.wml
english/intro/help.wml 11 Apr 2010 13:38:53 -0000 1.11
+++ english/intro/help.wml 22 Mar 2012 00:54:17 -0000
@@ -1,7 +1,9 @@
#use wml::debian::template title="How can you help Debian?"

-<p>If you are considering helping in the development of Debian GNU/Linux
-there are many areas in which both experienced and inexperienced users can assist:</p>
+<h2>As a "Net-New" User</h2>
+
+<p>New users can start right away, even with out installing or intending
+to use Debian. Though it's a good idea to at least try it once.</p>

# TBD - Describe requirements per task?
# such as: knowledge of english, experience in area X, etc..
@@ -14,13 +16,34 @@
the bugs associated with packages you use and provide further
information, if you can reproduce the issues described in them.</li>

-# TBD - link to users mailing lists
-# Translators, link directly to the translated mailing lists and provide
-# a link to the IRC channel in the user's language
-<li>If you are an experienced user you can help other users through
-the <a href="http://lists.debian.org/">user mailing lists</a> or
-by using the IRC channel <tt>#debian</tt>. For more information on support options
-and available sources read the <a href="$(HOME)/support">support pages</a>.</li>
+<li>Help Debian keep track of your favorite applications in the
+<a href="$(HOME)/devel/wnpp/">Work-Needing and Prospective Packages</a> lists.</li>
+
+# TBD - favorite features
+# Currently I'm unaware of a place to suggest "Better support for socks5"
+# 
+
+<li>You can help with the development of the <em>public</em> face of Debian and
+contribute to the <a href="$(HOME)/devel/website/">website</a> or by
+helping with the organisation of <a href="$(HOME)/events/">events</a>
+worldwide.</li>
+
+<li>You can <a href="$(HOME)/donations">donate equipment and services</a> to the Debian project so that
+either its users or developers can benefit from them. We are in constant search
+for <a href="$(HOME)/mirror/">mirrors worldwide</a> our users can rely on and
+<a href="$(HOME)/devel/buildd/">auto-builder systems</a> for our porters.</li>
+
+<li>Help Debian promoting itself by talking about it and demonstrating it to others.</li>
+
+</ol>
+
+<h2>Debian Labor</h2>
+
+<p>Debian is always looking for help and there are some areas where just being
+a worm body ready to learn new things is the perfect starting place.</p>
+
+<ol>

# TBD - link to translators mailing lists
# Translators, link directly to your group's pages
@@ -33,6 +56,25 @@
language. For more information read the <a
href="$(HOME)/international/">Internationalisation pages</a>.</li>

+<li>You can help writing copyright definitions for package maintainers in need.
+Best place to find one is
+<a href="http://mentors.debian.net/">...lt;/li>
+
+</ol>
+
+<h2>Debian Development</h2>
+
+<p>If you are considering helping in the development of Debian GNU/Linux
+there are many areas in which both experienced and inexperienced users can assist:</p>
+
+# TBD - link to users mailing lists
+# Translators, link directly to the translated mailing lists and provide
+# a link to the IRC channel in the user's language
+<li>If you are an experienced user you can help other users through
+the <a href="http://lists.debian.org/">user mailing lists</a> or
+by using the IRC channel <tt>#debian</tt>. For more information on support options
+and available sources read the <a href="../support">support pages</a>.</li>
+
<li>You can help maintain applications that are already available in the Debian
GNU/Linux operating system, specially those you use much and know about, by
contributing fixes (patches) or additional information in the <a
@@ -47,11 +89,6 @@
Project</a> or by contributing at the <a href="http://wiki.debian.org/">Debian
Wiki</a>.</li>

-<li>You can help with the development of the <em>public</em> face of Debian and
-contribute to the <a href="$(HOME)/devel/website/">website</a> or by
-helping with the organisation of <a href="$(HOME)/events/">events</a>
-worldwide.</li>
-
<li>You can help porting Debian to some architecture you are experienced with
either by starting a new port or contributing to existing ports. For more
information see the <a href="$(HOME)/ports/">list of available ports</a>.</li>
@@ -60,13 +97,6 @@
valuable for Debian and become the maintainer for those packages. For more
information read the <a href="$(HOME)/devel/">Debian Developer's Corner</a>.</li>

-<li>You can <a href="$(HOME)/donations">donate equipment and services</a> to the Debian project so that
-either its users or developers can benefit from them. We are in constant search
-for <a href="$(HOME)/mirror/">mirrors worldwide</a> our users can rely on and
-<a href="$(HOME)/devel/buildd/">auto-builder systems</a> for our porters.</li>
-
-<li>Help Debian promoting itself by talking about it and demonstrating it to others.</li>
-
</ol>

<p>As you can see, there are many ways you can get involved with the project

To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/4F6A7996.5040901@mikemestnik.net

Follow the discussion Replies

3 replies

Make a reply

Replies

#1 Jonathan Yu

March 21st, 2012 - 08:40 pm ET | Report spam

Hi Mike,

On Wed, Mar 21, 2012 at 9:00 PM, Mike Mestnik wrote:

I say one can easily split technical
and legal responsibility without the need for any gray lines.

While I am certainly not opposed to your idea in principle - that everyone
has something to contribute (including non-programmers) to Debian's
continued success - I think that for most packages, the problem would be
logistical.

From my experience working with the Debian Perl Group as a contributor but

not a Debian Developer, our workflow works something like this:

1. An interested party commits desired changes with corresponding
debian/changelog updates to the team repository

2. The Package Entropy Tracker notices the change, and flags it as Pending
Upload

3. A Debian Developer reviews the package and provides sponsorship
(uploading the work on behalf of the original contributor) if applicable,
or requests further changes

When it comes to copyright and licensing information, which is typically a
matter of looking through the accompanying documentation and leaving
appropriate notes in debian/copyright, it is typically a small job that is
done along with the rest of the packaging process. One nice way of doing a
quick spot check is using "grep -ir copyright ." to find all instances of
the word "copyright" in the source files. Logistically, requiring
developers to wait for an external party to work on copyright information
(which typically doesn't take too long in my experience) would
significantly slow down at least the Debian Perl Group's ability to process
and upload packages.

When it comes to translations, which I think is an area that recieves much
more non-developer attention than debian/copyright files, the logistical
issue still arises - but since we don't all write all of the languages in
existence, we often have no choice but to seek the assistance of interested
parties.

However, all that being said, I think that Debian can benefit from
interested parties assisting with copyright audits. We certainly have a lot
of metadata and a lot of code in the various Debian repositories - but how
accurately does that metadata (e.g. license and copyright information)
reflect the reality?

Moreover, there are a lot of open bug reports where we are blocked on an
ITP due to incomplete or missing copyright/licensing information - it would
be nice to have more eyes to look over these bugs, forward the information
upstream where appropriate, and follow up on open bug reports
(unfortunately, of which, there are many).

To sum up, the two places I see non-developer assistance being beneficial
to the Debian project (in the context of copyright and licensing
information) are:

1. Auditing of copyright/licensing information: ensure that the metadata
stored in debian/copyright is correct. This can be very difficult to do as
sometimes code is taken from other sources by upstream developers without
attribution.

2. Following up on bugs related to copyright/licensing information: for
cases where an ITP/RFP has been filed, but where copyright information is
not clear from the source data, file a bug report with the upstream
developers, or alternatively, ping the upstream developers in case the bug
has been overlooked. Possibly spend some time investigating alternative bug
trackers that the upstream developers may use instead, or their personal
e-mail addresses.

Cheers,

Jonathan

Hi Mike,<br><br><div class="gmail_quote">On Wed, Mar 21, 2012 at 9:00 PM, Mike Mestnik <span dir="ltr"><<a href="mailto:"></a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

I say one can easily split technical<br>
and legal responsibility without the need for any gray lines.<br></blockquote><div>Â <br>While I am certainly not opposed to your idea in principle - that everyone has something to contribute (including non-programmers) to Debian's continued success - I think that for most packages, the problem would be logistical.<br>

<br>From my experience working with the Debian Perl Group as a contributor but not a Debian Developer, our workflow works something like this:<br><br>1. An interested party commits desired changes with corresponding debian/changelog updates to the team repository<br>

<br>2. The Package Entropy Tracker notices the change, and flags it as Pending Upload<br><br>3. A Debian Developer reviews the package and provides sponsorship (uploading the work on behalf of the original contributor) if applicable, or requests further changes<br>

<br>When it comes to copyright and licensing information, which is typically a matter of looking through the accompanying documentation and leaving appropriate notes in debian/copyright, it is typically a small job that is done along with the rest of the packaging process. One nice way of doing a quick spot check is using "grep -ir copyright ." to find all instances of the word "copyright" in the source files. Logistically, requiring developers to wait for an external party to work on copyright information (which typically doesn't take too long in my experience) would significantly slow down at least the Debian Perl Group's ability to process and upload packages.<br>

<br>When it comes to translations, which I think is an area that recieves much more non-developer attention than debian/copyright files, the logistical issue still arises - but since we don't all write all of the languages in existence, we often have no choice but to seek the assistance of interested parties.<br>

<br>However, all that being said, I think that Debian can benefit from interested parties assisting with copyright audits. We certainly have a lot of metadata and a lot of code in the various Debian repositories - but how accurately does that metadata (e.g. license and copyright information) reflect the reality?<br>

<br>Moreover, there are a lot of open bug reports where we are blocked on an ITP due to incomplete or missing copyright/licensing information - it would be nice to have more eyes to look over these bugs, forward the information upstream where appropriate, and follow up on open bug reports (unfortunately, of which, there are many).<br>

<br>To sum up, the two places I see non-developer assistance being beneficial to the Debian project (in the context of copyright and licensing information) are:<br><br>1. Auditing of copyright/licensing information: ensure that the metadata stored in debian/copyright is correct. This can be very difficult to do as sometimes code is taken from other sources by upstream developers without attribution.<br>

<br>2. Following up on bugs related to copyright/licensing information: for cases where an ITP/RFP has been filed, but where copyright information is not clear from the source data, file a bug report with the upstream developers, or alternatively, ping the upstream developers in case the bug has been overlooked. Possibly spend some time investigating alternative bug trackers that the upstream developers may use instead, or their personal e-mail addresses.<br>

<br clear="all">Cheers,<br> <br>Jonathan<br></div></div>

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Archive: http://lists.debian.org/CAMDxSEipfO...UeJLBQQTw+

Read all the answers

debian/rules VS debian/copyright.

Replies

Similar topics