Debian Science Policy: First draft online and open for discussion

[Manuel Prinz-2]

Hello Debian Science,

a first draft of the Debian Science Policy is now available in the Debian
Science repository and can be checked out with:

  git clone git://git.debian.org/git/debian-science/policy.git

For easier reading, you should transform the document into XHTML. You can
simply run "make" to do so. (You do need to install the "xmlto" package, if
you don't have already.) The result is in the html/ sub-directory.

Sylvestre Ledru and I worked on that during the last days. This document is a
*draft* and we would like to hear your feedback on it! We were not sure if
everything is reasonable while writing it but tried to write down what
appeared to be best practices and/or "common sense". Of course, all points
are open for discussion and can be changed if we find a consensus. We hope
that especially those familiar with Git would comment on the VCS section. I
tried to write down what I found reasonable and git-buildpackage (mostly)
does. To those not yet familiar with Git: The HowTo will of course be
written, so you can follow it and learn Git. (It's not hard.) But it was
important to us to get a (mostly) complete draft out soon. (The HowTo will
match the Policy, of course.)

Besides the points mentioned in the document, the following points have to be
addressed:

1. What license should we use for the document?
2. Git usage: Should tags be signed?
3. How will the document be maintained?

For point 1, I personally propose the GPL v3 (or later). But I do not have
strong feelings about that.

For point 2, I personally do not see a real benefit of doing so, so I would
suggest it but not enforce it.

For point 3, Sylvestre and I have strong interest in maintaining the document
and would welcome anyone with a serious interested in it to help us. Writing
documents is usually not much fun and as you can see, a lot of it still needs
to be written. If you are interested, please email us! For changes of this
document Sylvestre and I think that a workflow similar to the Debian Policy
is reasonable, since most developers are already familiar with it. We would
act as a "gatekeeper" and lead discussions on critial sections, summarize the
result and propose a wording that should be seconded by people involved in
Debian Science. After that, we would include the change into the document.
One way to organize that is to package the policy as Debian package and use
the BTS for proposals. Your feedback on that is welcome!

We hope that you have no trouble reading and understanding the document. Both
of us are not native speakers and some parts of the document were written in
the night-time. We also did not want to sound bossy, and
every "should", "must" and "has to" is negotiable. It's a draft, after
all. ;)

One last point: We think that discussions about packaging topics should go to
the d-s-maintainers@... mailing list. But because not very much people
are subscribed there yet, we sent the announcement here. We encourage you to
subscribe to the maintainer mailing list. (And if the discussion gets to
noisy here, we probably should take it there.)

Best regards,
Manuel

[LaserJock]

On Tue, May 27, 2008 at 3:35 PM, Manuel Prinz <debian@...> wrote:

Hello Debian Science,

a first draft of the Debian Science Policy is now available in the Debian
Science repository and can be checked out with:

 git clone git://git.debian.org/git/debian-science/policy.git

Thanks for the work! It's great to have that in VCS.

Besides the points mentioned in the document, the following points have to be
addressed:

1. What license should we use for the document?
2. Git usage: Should tags be signed?
3. How will the document be maintained?

For point 1, I personally propose the GPL v3 (or later). But I do not have
strong feelings about that.

Seems reasonable to me. I doubt it matters much.
 

For point 2, I personally do not see a real benefit of doing so, so I would
suggest it but not enforce it.

This also seems reasonable.
 

For point 3, Sylvestre and I have strong interest in maintaining the document
and would welcome anyone with a serious interested in it to help us. Writing
documents is usually not much fun and as you can see, a lot of it still needs
to be written. If you are interested, please email us! For changes of this
document Sylvestre and I think that a workflow similar to the Debian Policy
is reasonable, since most developers are already familiar with it. We would
act as a "gatekeeper" and lead discussions on critial sections, summarize the
result and propose a wording that should be seconded by people involved in
Debian Science. After that, we would include the change into the document.
One way to organize that is to package the policy as Debian package and use
the BTS for proposals. Your feedback on that is welcome!

I think the "gatekeeper" workflow is appropriate. However, packaging the policy and using BTS seems like overkill. It would seem to me that with git, sending patches or merging from somebody's branch would be easy enough. I would think that discussion via the mailing list would get more discussion than using the BTS. 

 

We hope that you have no trouble reading and understanding the document. Both
of us are not native speakers and some parts of the document were written in
the night-time. We also did not want to sound bossy, and
every "should", "must" and "has to" is negotiable. It's a draft, after
all. ;)

There was only one spot where I had a question. In the debian/control section it says that the Section field should be "science". I can think of a lot of cases where a package would be in sections other than "science". For instance, "math", "electronics", "gnome", "kde", "libs" all seem logical as well.

Otherwise, I thought the "should"s and "must"s were approriate. As somebody who rarely uses CDBS and had never used quilt I'm glad those are "preffered" :-)

-Jordan

[Charles Plessy-12]

Le Wed, May 28, 2008 at 12:35:01AM +0200, Manuel Prinz a écrit :
>
> a first draft of the Debian Science Policy is now available in the Debian
> Science repository and can be checked out with:
>

Hi Manuel and Sylvestre,

Nice work :) I have a few comments and questions:

 - Why is 'Priority: extra' preferred over optional? What are the
   expected benefits?

 - It could be useful to request that the fields in debian/control are
   always used in the same order, to help repository-wide changes.

 - The match order in the machine-readable copyright format has been
   reversed compared to the original proposal. Therefore, your example
   is slightly outdated.

 - For the license of the packaging work, I recommend to require that
   its license is not more restrictive than the original source, so that
   patches do not cause problems when forwarded upstream.


> 1. What license should we use for the document?

Unless you have concerns that the document can be forked and
close-sourced, using GPL is probably too much and will open the
possibility of arguments at the GPLv4 transition :)


Have a nice day,

--
Charles Plessy
http://charles.plessy.org
Wakō, Saitama, Japan


--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Charles Plessy-12]

Le Tue, May 27, 2008 at 04:10:18PM -0700, Jordan Mantha a écrit :
>
>    There was only one spot where I had a question. In the debian/control
>    section it says that the Section field should be "science". I can think of a
>    lot of cases where a package would be in sections other than "science". For
>    instance, "math", "electronics", "gnome", "kde", "libs" all seem logical as
>    well.

Hi Jordan,

Actually, there can be a Section field for the source and the binary
packages. Maybe that can solve the problem ?

Have a nice day,

--
Charles Plessy
http://charles.plessy.org
Wakō, Saitama, Japan


--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[LaserJock]

On Tue, May 27, 2008 at 5:49 PM, Charles Plessy <plessy@...> wrote:

Le Tue, May 27, 2008 at 04:10:18PM -0700, Jordan Mantha a écrit :

>
>    There was only one spot where I had a question. In the debian/control
>    section it says that the Section field should be "science". I can think of a
>    lot of cases where a package would be in sections other than "science". For
>    instance, "math", "electronics", "gnome", "kde", "libs" all seem logical as
>    well.

Hi Jordan,

Actually, there can be a Section field for the source and the binary
packages. Maybe that can solve the problem ?

Perhaps. The reason I wondered is because plotdrop, which I just put in the git repo, has Section: math . Would I want to change that or is it not a big deal?

-Jordan

[Sylvestre Ledru-3]

Hello,

>  - It could be useful to request that the fields in debian/control are
>    always used in the same order, to help repository-wide changes.
Yep, good point. We now have to define the order !

>  - The match order in the machine-readable copyright format has been
>    reversed compared to the original proposal. Therefore, your example
>    is slightly outdated.
OK, we will update them.

>  - For the license of the packaging work, I recommend to require that
>    its license is not more restrictive than the original source, so that
>    patches do not cause problems when forwarded upstream.
Maybe it is badly placed in the document but there is a sentence about
that which says almost the same as you:
"The license of the packaging work should either match the license of the upstream sources or have a license that is compatible with the upstream license."

Sylvestre



--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Charles Plessy-12]

Hi Sylvestre,

> >  - For the license of the packaging work, I recommend to require that
> >    its license is not more restrictive than the original source, so that
> >    patches do not cause problems when forwarded upstream.

> Maybe it is badly placed in the document but there is a sentence about
> that which says almost the same as you:
> "The license of the packaging work should either match the license of the upstream sources or have a license that is compatible with the upstream license."

This wording does not prevent having GPL'ed patches to send to a
BSD-licenced project, which is something I would personnaly not like to
have to do… This can happen as quickly as having somebody commiting a
patch for a package whose Debian side is GPL'ed because this is the
default licence in the dh_make templates, and then going MIA.

Have a nice day,

--
Charles


--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Sylvestre Ledru-3]

Le mercredi 28 mai 2008 à 18:27 +0900, Charles Plessy a écrit :

> Hi Sylvestre,
>
> > >  - For the license of the packaging work, I recommend to require that
> > >    its license is not more restrictive than the original source, so that
> > >    patches do not cause problems when forwarded upstream.
>
> > Maybe it is badly placed in the document but there is a sentence about
> > that which says almost the same as you:
> > "The license of the packaging work should either match the license of the upstream sources or have a license that is compatible with the upstream license."
>
> This wording does not prevent having GPL'ed patches to send to a
> BSD-licenced project

Hu? It does: "have a license that is compatible with the upstream
license"
Taking your example, the GPL is incompatible with the BSD, then, GPL
should not be the one used for your packaging work.

Sylvestre



--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Charles Plessy-12]

Le Wed, May 28, 2008 at 11:33:07AM +0200, Sylvestre Ledru a écrit :
> Taking your example, the GPL is incompatible with the BSD, then, GPL
> should not be the one used for your packaging work.

Ah, OK, we have a vocabulary mismatch then. I was thinking that the GPL
is compatible with the BSD (but contaminates it).

I will follow the opinion of the majority to solve this :)

Have a nice day,

--
Charles


--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Andreas Tille]

On Wed, 28 May 2008, Manuel Prinz wrote:

>  git clone git://git.debian.org/git/debian-science/policy.git

Any tips for people sitting behind a firewall that only allows
html (via proxy) and who will get:

$ git clone git://git.debian.org/git/debian-science/policy.git
Initialized empty Git repository in /home/tillea/debian-maintain/alioth/debian-science/git/policy/.git/
git.debian.org[0: 217.196.43.134]: errno=Connection refused
fatal: unable to connect a socket (Connection refused)
fetch-pack from 'git://git.debian.org/git/debian-science/policy.git' failed.

Kind regards

          Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Andreas Tille]

On Wed, 28 May 2008, Sylvestre Ledru wrote:

> Taking your example, the GPL is incompatible with the BSD, then, GPL
> should not be the one used for your packaging work.

Why not "... licensed under either GPL or BSD"?  This makes sure that
it might fit any license in case there is some conflict.

Kind regards

       Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Manuel Prinz-2]

Hi Charles,

thanks for your feedback!

Am Mittwoch, den 28.05.2008, 09:47 +0900 schrieb Charles Plessy:
>  - Why is 'Priority: extra' preferred over optional? What are the
>    expected benefits?

This is one of the things I thought to be "common practice" in several
team. I never really got the need for differing between "extra" and
"optional", so I can't argue about them. I would also be fine with
setting all to "optional".

>  - It could be useful to request that the fields in debian/control are
>    always used in the same order, to help repository-wide changes.

I do not have strong feelings about that.

>  - The match order in the machine-readable copyright format has been
>    reversed compared to the original proposal. Therefore, your example
>    is slightly outdated.

Thanks for pointing that out, I was not aware of that! I also found a
problem in an other example, so I'll update those.

>  - For the license of the packaging work, I recommend to require that
>    its license is not more restrictive than the original source, so that
>    patches do not cause problems when forwarded upstream.

I think this makes perfect sense. I is what I intended with the wording
but it was not clear. As you pointed out in the thread, GPL patches
"contaminate" a BSD upstream. This should indeed be avoided.

> > 1. What license should we use for the document?
>
> Unless you have concerns that the document can be forked and
> close-sourced, using GPL is probably too much and will open the
> possibility of arguments at the GPLv4 transition :)

I'm fine with it not being GPL. I think that very few people will be
interested in forking it anyway. PD or some free CC would be fine with
me.

Best regards
Manuel

[Manuel Prinz-2]

Am Mittwoch, den 28.05.2008, 12:33 +0200 schrieb Andreas Tille:

> On Wed, 28 May 2008, Manuel Prinz wrote:
>
> >  git clone git://git.debian.org/git/debian-science/policy.git
>
> Any tips for people sitting behind a firewall that only allows
> html (via proxy) and who will get:
>
> $ git clone git://git.debian.org/git/debian-science/policy.git
> Initialized empty Git repository in /home/tillea/debian-maintain/alioth/debian-science/git/policy/.git/
> git.debian.org[0: 217.196.43.134]: errno=Connection refused
> fatal: unable to connect a socket (Connection refused)
> fetch-pack from 'git://git.debian.org/git/debian-science/policy.git' failed.

Sorry, forgot to enable support for protocols like HTTP. I will enable
it and let you know. If you can ssh out, you can also use git via the
ssh transport. Just change the protocol from "git" to "ssh+git".

Best regards
Manuel

[Manuel Prinz-2]

Hi Jordan,

thanks for the feedback!

Am Dienstag, den 27.05.2008, 16:10 -0700 schrieb Jordan Mantha:

> I think the "gatekeeper" workflow is appropriate. However, packaging
> the policy and using BTS seems like overkill. It would seem to me that
> with git, sending patches or merging from somebody's branch would be
> easy enough. I would think that discussion via the mailing list would
> get more discussion than using the BTS.

OK. So I would suggest to send patches to -maintainers, and have a discussion there.

Everyone can already follow the progress by subscribing to -commits to
track changes to the document. Replies to commit emails will go to
-maintainers. (The list is already configured to take care of that.)

> There was only one spot where I had a question. In the debian/control
> section it says that the Section field should be "science". I can
> think of a lot of cases where a package would be in sections other
> than "science". For instance, "math", "electronics", "gnome", "kde",
> "libs" all seem logical as well.

I just thought about a common value for it because there are a lot of
scientific disciplines that do not have a section value. As I can see,
it's just "math" and "electronics". I never got Sections like "kde" or
"gnome" since they do not provide real information, except that an
application may be part of KDE or GNOME, so others than their base
packages should not set those. IMHO the whole Section stuff is
superseeded by DebTags anyway but it has to be set. I'm fine with having
"math" in there and can change the wording accordingly.

Of course, binary packages should set it according to their function,
such as "libs" or "libdevel". I'll make that more clear.

Best regards
Manuel

[Manuel Prinz-2]

Am Mittwoch, den 28.05.2008, 12:50 +0200 schrieb Manuel Prinz:
> I will enable it and let you know.

Done, easier as expected. You can now also clone using:

  git clone http://git.debian.org/git/debian-science/policy.git

Best regards
Manuel

[Manuel Prinz-2]

Am Mittwoch, den 28.05.2008, 12:39 +0200 schrieb Andreas Tille:
> Why not "... licensed under either GPL or BSD"?  This makes sure that
> it might fit any license in case there is some conflict.

In my understanding the problem is not so much about conflicting license
but about mixing compatible license with different definitions of
"free". Having GPL patches in a BSD codebase may cause trouble in case
of (i.e.) relicensing and should be avoided. The easiest solution seems
to be to use upstream's license or a license that is even "more free".

Best regards
Manuel

[Manuel Prinz-2]

Am Dienstag, den 27.05.2008, 17:54 -0700 schrieb Jordan Mantha:
> The reason I wondered is because plotdrop, which I just put in the git
> repo, has Section: math . Would I want to change that or is it not a
> big deal?

I don't think it is a big deal and can stay that way.

Best regards
Manuel

[Bernhard R. Link-2]

* Manuel Prinz <debian@...> [080528 00:34]:
>   git clone git://git.debian.org/git/debian-science/policy.git

> Besides the points mentioned in the document, the following points have to be
> addressed:
>
> 1. What license should we use for the document?

Is there so much in the worth protectable? Otherwise making it public
domain or basically public domain looks also like a choice to consider.

Suggestions about the draft:

| The <ulink url="http://wiki.debian.org/Proposals/CopyrightFormat">
| machine-readable format</ulink> must be used.

That format has still quite a bit of "yet to be discussed" in it.
It also has still quite some shortcoming with complicated distribution
about Copyright owners. That about a ", as long as expressable this
way." added to this?

| The <varname>DM-Upload-Allowed</varname> should be included and set to
| "yes".

I do not think adding this field as along as there are no Uploaders is
that sensible. I'd rather suggest some rule that this field should not
be removed without the consents of the "Uploaders" or something like
that. (Because I definitly will not sponsor/upload any package with this
header set unless the header and the same set of uploaders is already in the
archive (and even then only with feeling pain)).

| but <ulink url="http://packages.debian.org/cdbs">CDBS</ulink> is preferred.

Just my 0.02¢ vote against this. (Or at least mention debhelper as equal).

* Other stuff:

I'm missing something explicit about general comitt rights/etiquette.
Can anyone add himself to the Uploaders of every package? Who is allowed to
make which modifications to which packages's repository? Are obvious
non-intrusive fixes in other people's packages in the project ok?
And stuff like that.

Hochachtungsvoll,
        Bernhard R. Link


--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...