Re: Usage of DEP5

2019-11-14 Thread Sean Whitton
Hello gregor,

On Tue 12 Nov 2019 at 11:32PM +01, gregor herrmann wrote:

> I was not aware of a difference in strength between the two
> recommendation [0] but yes, the "people with no reason to prefer
> either" was the direction I was heading at.

Well, dh is a recommendation of Policy, but usage of salsa is not going
in a document with anything like the normative weight of Policy.

Anyway, seems that we agree.  Thanks!

-- 
Sean Whitton


signature.asc
Description: PGP signature


Re: Usage of DEP5

2019-11-13 Thread Thorsten Glaser
gregor herrmann dixit:
>On Tue, 12 Nov 2019 15:08:56 -0700, Sean Whitton wrote:
>> optimising for writing these files, I don't think we should be expecting
>> people to come up with a package-specific reason if they find themselves

Thanks.

>> I'd like to suggest this recommendation could be of the same strength as
>> the "use salsa" recommendation, i.e., weaker than the dh recommendation,
>> and directed at people with no reasons to prefer either who are
>> wondering which to use.
>
>I was not aware of a difference in strength between the two
>recommendation [0] but yes, the "people with no reason to prefer
>either" was the direction I was heading at.

Fine with me. (As I said, I do have packages with either, and I agree
the new format can be more suitable.)

Thanks,
//mirabilos
-- 
[00:02]  gecko: benutzt du emacs ?
[00:03]  nö  [00:03]  nur n normalen mac
[00:04]  argl   [00:04]  ne den editor
-- Vutral und gecko2 in #deutsch (NB: Editor? Betriebssystem.)



Re: Usage of DEP5

2019-11-13 Thread Andreas Tille
On Sun, Nov 10, 2019 at 09:49:26PM +0100, Daniel Leidert wrote:
> Am Donnerstag, den 07.11.2019, 13:40 + schrieb Thorsten Glaser:
> 
> [snip]
> > If forcing machine-readable copyright is required for UMEGAYA,
> > then I’m sorry to say I will be removing debian/upstream/metadata
> > from some of my packages rather.
> 
> Why is a machine-readable debian/copyright (DEP5, accepted) mixed with
> debian/upstream/metadata (DEP12, just a draft) here?
> 
> debian/upstream/metadata is completely optional. This draft has not even been
> accepted yet. I see heavy issues making this mandatory. It contains almost 
> only
> non-packaging relevant information, which is not really necessary to provide
> that package. And the data contained can change at any time.

The connection is that I was arguing that fields that are in DEP5 should
not be in DEP12.  Those who refuse to use DEP5 might like to put that
into DEP12 (see my first mail in this thread about the Wiki change[1]).
I basically started the thread here since I disagree.  To say it
clearly:  If you want to ship the information that is shiped in DEP5 you
should use DEP5.  Sticking to the old copyright format and sneaking in
the information "somewhere else" does not make any sense to me.
 
> But if we don't ship the projects license(s) files, debian/copyright IS
> mandatory. JFTR: I don't understand why a formalized format of 
> debian/copyright
> is that hard to realize.

+1

I could understand "I don't have time"-like excuses.  I have not seen
any example yet, that would be hard to re-phrase as valid copyright
format 1.0.

Kind regards

  Andreas.

[1] https://lists.debian.org/debian-devel/2019/11/msg00096.html

-- 
http://fam-tille.de



Re: Usage of DEP5

2019-11-13 Thread Andreas Tille
On Wed, Nov 13, 2019 at 06:07:46AM -0500, Sam Hartman wrote:
> > "Andreas" == Andreas Tille  writes:
> 
> Andreas> On Tue, Nov 12, 2019 at 11:32:09PM +0100, gregor herrmann wrote:
> >> > I'd like to suggest this recommendation could be of the same
> >> strength as > the "use salsa" recommendation, i.e., weaker than
> >> the dh recommendation, > and directed at people with no reasons
> >> to prefer either who are > wondering which to use.
> >> 
> >> I was not aware of a difference in strength between the two
> >> recommendation [0]
> 
> Andreas> I also was not aware that there are different strengths of
> Andreas> recommendation. ;-)
> 
> I think we'd all be kind of confused if someone started filing bugs
> because a package was not in salsa.

OK, I agree that this makes a technical difference between the two
recommendations.
 
> Andreas> Definitely.  Moreover, may be I have missed it but the
> Andreas> question to some example where the free form text is easier
> Andreas> to read than the machine readable one was not answered yet.
> Andreas> I'm keen on reading this.
> 
> 
> It sounds like there's a proposal here with some support.
> does someone want to facilitate this discussion?
> 
> * Pay attention to any issues that get brought up
> 
> * Summarize at the end
> 
> * If there is consensus to make a recommendation, figure out where it
>   should go and file a bug  pointing to the summary.
> 
> I don't think facilitating the discussion should obligate someone to
> write text for dev ref or policy or Shepherd things through those
> processes.
> Although obviously, the more work you put into it, the faster things
> might happen.

Since I somehow started the discussion I would draw some kind of
obligation out of it.  Unfortunately I'm suffering from some vacation
backlog and will enter a Bioinformatics sprint next week which will
probably not leave me any spare minute for this.

In short: I'm not up for this for the next two weeks but I'd happily
support by proof-reading if somebody would be faster than me.

Kind regards

  Andreas.

-- 
http://fam-tille.de



Re: Usage of DEP5

2019-11-13 Thread Sam Hartman
> "Andreas" == Andreas Tille  writes:

Andreas> On Tue, Nov 12, 2019 at 11:32:09PM +0100, gregor herrmann wrote:
>> > I'd like to suggest this recommendation could be of the same
>> strength as > the "use salsa" recommendation, i.e., weaker than
>> the dh recommendation, > and directed at people with no reasons
>> to prefer either who are > wondering which to use.
>> 
>> I was not aware of a difference in strength between the two
>> recommendation [0]

Andreas> I also was not aware that there are different strengths of
Andreas> recommendation. ;-)

I think we'd all be kind of confused if someone started filing bugs
because a package was not in salsa.

There are cases where not using dh is a non-RC bug, and there are
probably cases where having someone other than the maintainer file that
bug makes sense.

>> but yes, the "people with no reason to prefer either" was the
>> direction I was heading at.

Andreas> Definitely.  Moreover, may be I have missed it but the
Andreas> question to some example where the free form text is easier
Andreas> to read than the machine readable one was not answered yet.
Andreas> I'm keen on reading this.


It sounds like there's a proposal here with some support.
does someone want to facilitate this discussion?

* Pay attention to any issues that get brought up

* Summarize at the end

* If there is consensus to make a recommendation, figure out where it
  should go and file a bug  pointing to the summary.

I don't think facilitating the discussion should obligate someone to
write text for dev ref or policy or Shepherd things through those
processes.
Although obviously, the more work you put into it, the faster things
might happen.



Re: Usage of DEP5

2019-11-13 Thread Andreas Tille
On Tue, Nov 12, 2019 at 11:32:09PM +0100, gregor herrmann wrote:
> > I'd like to suggest this recommendation could be of the same strength as
> > the "use salsa" recommendation, i.e., weaker than the dh recommendation,
> > and directed at people with no reasons to prefer either who are
> > wondering which to use.
>  
> I was not aware of a difference in strength between the two
> recommendation [0]

I also was not aware that there are different strengths of
recommendation. ;-)

> but yes, the "people with no reason to prefer
> either" was the direction I was heading at.

Definitely.  Moreover, may be I have missed it but the question to some
example where the free form text is easier to read than the machine
readable one was not answered yet.  I'm keen on reading this.

Kind regards

 Andreas.

> [0] I'm probably not in the target group as I'm doing it anyway

-- 
http://fam-tille.de



Re: Usage of DEP5

2019-11-12 Thread gregor herrmann
On Tue, 12 Nov 2019 15:08:56 -0700, Sean Whitton wrote:

> On Sat 09 Nov 2019 at 03:07PM +01, gregor herrmann wrote:
> > Lately we as a project, guided by the DPL, have been in
> > recommendation mode anyway: "Use dh(1) unless you have a reason not
> > to", "Use git(1) and salsa unless …".
> > I think "Write d/copyright in Copyright-Format 1.0 unless you have a
> > specific reason not to do this for a specific package" would be a
> > good continuation of this streak.
> I too find this a bit strong -- given what I've said about about
> optimising for writing these files, I don't think we should be expecting
> people to come up with a package-specific reason if they find themselves
> wanting to use the old format.

Fair enough (and I'm not wed to the throw-away wording in any way.)
 
> I'd like to suggest this recommendation could be of the same strength as
> the "use salsa" recommendation, i.e., weaker than the dh recommendation,
> and directed at people with no reasons to prefer either who are
> wondering which to use.
 
I was not aware of a difference in strength between the two
recommendation [0] but yes, the "people with no reason to prefer
either" was the direction I was heading at.


Cheers,
gregor


[0] I'm probably not in the target group as I'm doing it anyway

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Element of Crime: Black and White


signature.asc
Description: Digital Signature


Re: Usage of DEP5

2019-11-12 Thread Sean Whitton
Hello,

On Sat 09 Nov 2019 at 03:07PM +01, gregor herrmann wrote:

> Lately we as a project, guided by the DPL, have been in
> recommendation mode anyway: "Use dh(1) unless you have a reason not
> to", "Use git(1) and salsa unless …".
>
> I think "Write d/copyright in Copyright-Format 1.0 unless you have a
> specific reason not to do this for a specific package" would be a
> good continuation of this streak.

I too find this a bit strong -- given what I've said about about
optimising for writing these files, I don't think we should be expecting
people to come up with a package-specific reason if they find themselves
wanting to use the old format.

I'd like to suggest this recommendation could be of the same strength as
the "use salsa" recommendation, i.e., weaker than the dh recommendation,
and directed at people with no reasons to prefer either who are
wondering which to use.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Re: Usage of DEP5

2019-11-10 Thread Daniel Leidert
Am Donnerstag, den 07.11.2019, 13:40 + schrieb Thorsten Glaser:

[snip]
> If forcing machine-readable copyright is required for UMEGAYA,
> then I’m sorry to say I will be removing debian/upstream/metadata
> from some of my packages rather.

Why is a machine-readable debian/copyright (DEP5, accepted) mixed with
debian/upstream/metadata (DEP12, just a draft) here?

debian/upstream/metadata is completely optional. This draft has not even been
accepted yet. I see heavy issues making this mandatory. It contains almost only
non-packaging relevant information, which is not really necessary to provide
that package. And the data contained can change at any time.

But if we don't ship the projects license(s) files, debian/copyright IS
mandatory. JFTR: I don't understand why a formalized format of debian/copyright
is that hard to realize.

Regards, Daniel




signature.asc
Description: This is a digitally signed message part


Re: Usage of DEP5

2019-11-09 Thread Paul Wise
On Sun, Nov 10, 2019 at 1:40 AM Russ Allbery wrote:

> Maybe one of these days I'll take a couple of days and turn it into
> something vaguely maintainable and usable by someone else.

We already have a lot of similar tools for this, unfortunately the
most accurate ones (FOSSology & ScanCode) aren't available in Debian
right now, although folks are working on that. FOSSology has an ITP &
RFS and a GSoC student apparently worked on or is working on ScanCode
packaging. ScanCode doesn't yet support the Debian copyright output
format but FOSSology does.

https://wiki.debian.org/CopyrightReviewTools
https://lwn.net/Articles/803725/
https://osr.cs.fau.de/2019/08/07/final-thesis-a-comparison-study-of-open-source-license-crawler/
https://bugs.debian.org/924659
https://bugs.debian.org/926915
https://github.com/nexB/scancode-toolkit/issues/469
https://github.com/nexB/scancode-toolkit/issues/472

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



Re: Usage of DEP5

2019-11-09 Thread Jeremy Bicha
On Sat, Nov 9, 2019 at 4:16 PM Scott Kitterman  wrote:
> On Saturday, November 9, 2019 3:05:21 PM EST Ole Streicher wrote:
> > Hi Scott,
> >
> > Scott Kitterman  writes:
> > > I'd like to suggest thinking about this from the perspective of new
> > > contributors.  Copyright-format 1.0 has a lot of specific requirements.
> > > Do we really want to recommend that before someone can package software
> > > for Debian they need to learn this too (hint: I think no - there's plenty
> > > to learn to get started that's actually necessary).
> >
> > I am surprised here, since I would recommend exactly the opposite: For a
> > beginner, a well-structured format is much better to fill in than a "The
> > copyright must be somehow documented in d/copyright".
> >
> > CF1.0 helps since it makes clear which information to put there, one
> > doesn't have to think about the structure etc. Especially with the help
> > of the sponsor.
> >
> > Following magic rules really helps starting to contribute.
>
> I think there are enough "Oh, you missed a colon here, please fix and I'll
> review again" in Debian packaging without adding more.  Fundamentally,
> copyright-format 1.0 adds a pile of possible things to get wrong that are
> actually in no way relevant to the purpose of debian/copyright.  Focusing on
> form over function isn't the first thing contributors need to learn.

Sorry to be a jerk. And sorry to go off-topic. But…

I feel like new contributors are discouraged by the inconsistent and
sometimes overly formal copyright documentation rejection criteria.
For instance, the first point mentioned in the ftpmaster rejection
email is a rejection for not specifying the license of autotools
cruft. The packager (who is neither a DD nor a DM) has told me that
they feel like they might as well switch the buildsystem to meson, not
necessarily because of any technical build improvements, but primarily
to make it easier to appease the ftpmasters.

It does not feel right to me that packages that use Copyright Format
1.0 are held to a **higher** standard than packages that don't.

I personally have spent many hours working on a singler package that
was required for GNOME to work (mozjs38) just to try to build a
complete enough d/copyright file to clear the NEW queue. And I am an
experienced packager.

[1] 
https://alioth-lists.debian.net/pipermail/pkg-ayatana-devel/2019-September/002438.html

Thanks,
Jeremy Bicha



Re: Usage of DEP5

2019-11-09 Thread Scott Kitterman
On Saturday, November 9, 2019 3:05:21 PM EST Ole Streicher wrote:
> Hi Scott,
> 
> Scott Kitterman  writes:
> > I'd like to suggest thinking about this from the perspective of new
> > contributors.  Copyright-format 1.0 has a lot of specific requirements. 
> > Do we really want to recommend that before someone can package software
> > for Debian they need to learn this too (hint: I think no - there's plenty
> > to learn to get started that's actually necessary).
> 
> I am surprised here, since I would recommend exactly the opposite: For a
> beginner, a well-structured format is much better to fill in than a "The
> copyright must be somehow documented in d/copyright".
> 
> CF1.0 helps since it makes clear which information to put there, one
> doesn't have to think about the structure etc. Especially with the help
> of the sponsor.
> 
> Following magic rules really helps starting to contribute.

I think there are enough "Oh, you missed a colon here, please fix and I'll 
review again" in Debian packaging without adding more.  Fundamentally, 
copyright-format 1.0 adds a pile of possible things to get wrong that are 
actually in no way relevant to the purpose of debian/copyright.  Focusing on 
form over function isn't the first thing contributors need to learn.

Scott K

signature.asc
Description: This is a digitally signed message part.


Re: Usage of DEP5

2019-11-09 Thread Ole Streicher
Hi Scott,

Scott Kitterman  writes:
> I'd like to suggest thinking about this from the perspective of new 
> contributors.  Copyright-format 1.0 has a lot of specific requirements.  Do 
> we 
> really want to recommend that before someone can package software for Debian 
> they need to learn this too (hint: I think no - there's plenty to learn to 
> get 
> started that's actually necessary).

I am surprised here, since I would recommend exactly the opposite: For a
beginner, a well-structured format is much better to fill in than a "The
copyright must be somehow documented in d/copyright".

CF1.0 helps since it makes clear which information to put there, one
doesn't have to think about the structure etc. Especially with the help
of the sponsor.

Following magic rules really helps starting to contribute.

Cheers

Ole



Re: Usage of DEP5

2019-11-09 Thread Scott Kitterman
On Saturday, November 9, 2019 9:07:39 AM EST gregor herrmann wrote:
> On Thu, 07 Nov 2019 13:40:28 +, Thorsten Glaser wrote:
> 
> Some remarks:
> > Andreas Tille dixit:
> > >explicit wish to not use DEP5.  I wonder what other reasons might exist
> > >to explicitly stick to the non-machine readable format.
> > 
> > I prefer human-readable format. I also often deal in software which
> > has more… flexibility than the DEP 5 format allows, or where it is
> > plain simpler.
> 
> - It's called "Copyright Format 1.0" since a couple of years, DEP5
>   was during the development state.
> - Personally I find d/copyright files in CF 1.0 much more readable
>   than free-form prose where I have to find the relevant information
>   somewhere instead of having it stand out. Maybe that makes me a
>   machine :) or maybe "maching-readable" is not the best
>   characterization of CF 1.0
> 
> Anyway:
> > I have no problem with it in general, as long as it’s not forced.
> > It’s clearly a 90%+ solution, not a 100% solution.
> 
> This sounds like a very good compromise to me.
> 
> Lately we as a project, guided by the DPL, have been in
> recommendation mode anyway: "Use dh(1) unless you have a reason not
> to", "Use git(1) and salsa unless …".
> 
> I think "Write d/copyright in Copyright-Format 1.0 unless you have a
> specific reason not to do this for a specific package" would be a
> good continuation of this streak.

I'd like to suggest thinking about this from the perspective of new 
contributors.  Copyright-format 1.0 has a lot of specific requirements.  Do we 
really want to recommend that before someone can package software for Debian 
they need to learn this too (hint: I think no - there's plenty to learn to get 
started that's actually necessary).

I started learning Debian packaging in 2007.  Looking back at all the 
complexity we've added since, I'm not completely sure if I were approaching it 
new today I wouldn't throw up my hands and declare it too complicated.

I believe we should be really careful about raising barriers to entry and 
pushing too hard on copyright-format 1.0 would be one that is totally uneeded.

Scott K


signature.asc
Description: This is a digitally signed message part.


Re: Usage of DEP5

2019-11-09 Thread Russ Allbery
gregor herrmann  writes:
> On Fri, 08 Nov 2019 10:51:45 -0700, Sean Whitton wrote:

>> DEP-5 is the fastest way to write a d/copyright in some cases, but in
>> others it is not.  Part of this is that DEP-5 somewhat encourages people
>> to include more detail than is needed.
>> 
>> I think we should be optimising for reduced contributor time spent on
>> this task.

> That's a totally reasonable point of course.
> I'd like to add that d/copyright is not only written but also read,
> and that there are contributors who find Copyright-Format 1.0 easier
> to read. 

Personally, I wrote a program to generate a Copyright-Format 1.0 file for
my packages, which makes it easier on all fronts than hand-maintaining the
file and is about as optimized for reduced contributor time as I can get.
(Every once in a while I have to tweak the script and curse the hacky way
that I wrote it.)

The script is an undocumented mess and only works with the specific
patterns of copyright and license notices that I've taught it, so everyone
else would be better off using licensecheck, but that's the same basic
idea.

Maybe one of these days I'll take a couple of days and turn it into
something vaguely maintainable and usable by someone else.

-- 
Russ Allbery (r...@debian.org)  



Re: Usage of DEP5

2019-11-09 Thread Thorsten Glaser
gregor herrmann dixit:

>Lately we as a project, guided by the DPL, have been in
>recommendation mode anyway: "Use dh(1) unless you have a reason not
>to", "Use git(1) and salsa unless …".
>
>I think "Write d/copyright in Copyright-Format 1.0 unless you have a
>specific reason not to do this for a specific package" would be a
>good continuation of this streak.

I find them worded too strongly personally, but given almost all
of my paackages are leaf and not team-maintained, I doubt I’d be
too pressured towards it, and with that understanding could live
with it. (In particular, Salsa is something I’m very uncomforta‐
ble with, considering it’s a non-free service not even using the
packaged form, which itself is not suitable for stable, too…)

More on-topic:

>- Personally I find d/copyright files in CF 1.0 much more readable
>  than free-form prose where I have to find the relevant information
>  somewhere instead of having it stand out. Maybe that makes me a

I guess it depends, a well-written hand-written file may surprise
you with regards to legibility, but too-quickly-cobbled-together,
perhaps even unmaintained, ones… yes, I’ve seen those, too.

bye,
//mirabilos
-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.  -- Coywolf Qi Hunt



Re: Usage of DEP5

2019-11-09 Thread gregor herrmann
On Fri, 08 Nov 2019 10:51:45 -0700, Sean Whitton wrote:

> DEP-5 is the fastest way to write a d/copyright in some cases, but in
> others it is not.  Part of this is that DEP-5 somewhat encourages people
> to include more detail than is needed.
> 
> I think we should be optimising for reduced contributor time spent on
> this task.

That's a totally reasonable point of course.
I'd like to add that d/copyright is not only written but also read,
and that there are contributors who find Copyright-Format 1.0 easier
to read. 


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Joel Harrison: Twelve gates to the city


signature.asc
Description: Digital Signature


Re: Usage of DEP5

2019-11-09 Thread gregor herrmann
On Thu, 07 Nov 2019 13:40:28 +, Thorsten Glaser wrote:

Some remarks:

> Andreas Tille dixit:
> >explicit wish to not use DEP5.  I wonder what other reasons might exist
> >to explicitly stick to the non-machine readable format.
> I prefer human-readable format. I also often deal in software which
> has more… flexibility than the DEP 5 format allows, or where it is
> plain simpler.

- It's called "Copyright Format 1.0" since a couple of years, DEP5
  was during the development state.
- Personally I find d/copyright files in CF 1.0 much more readable
  than free-form prose where I have to find the relevant information
  somewhere instead of having it stand out. Maybe that makes me a
  machine :) or maybe "maching-readable" is not the best
  characterization of CF 1.0  


Anyway:
 
> I have no problem with it in general, as long as it’s not forced.
> It’s clearly a 90%+ solution, not a 100% solution.

This sounds like a very good compromise to me.

Lately we as a project, guided by the DPL, have been in
recommendation mode anyway: "Use dh(1) unless you have a reason not
to", "Use git(1) and salsa unless …".

I think "Write d/copyright in Copyright-Format 1.0 unless you have a
specific reason not to do this for a specific package" would be a
good continuation of this streak.
 

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Eric Clapton: Cocaine


signature.asc
Description: Digital Signature


Re: Usage of DEP5

2019-11-08 Thread Scott Kitterman



On November 8, 2019 6:29:05 PM UTC, Simon McVittie  wrote:
>On Fri, 08 Nov 2019 at 10:51:45 -0700, Sean Whitton wrote:
>> DEP-5 is the fastest way to write a d/copyright in some cases, but in
>> others it is not.  Part of this is that DEP-5 somewhat encourages
>people
>> to include more detail than is needed.
>
>It would probably help if we had more clarity around what is needed: at
>the moment the only way to know what is required is to upload to NEW
>and
>see whether the package is accepted. Maintainers don't want their
>packages
>to get additional delays from NEW rejection, so they have to err on the
>side of including everything that the ftp team might possibly require.
>
>Omitting the license grant (#904729, which is blocked on ftp team
>feedback) would be one good way to reduce the amount of boilerplate
>we're pasting into the copyright file.
>
>If the per-file copyright information is something that is encouraged
>by DEP-5 but not strictly needed: perhaps it would be viable to
>suggest,
>or even encourage, changing this:
>
>Format: imagine the correct URL is here
>
>Files: a.c a.h aaa.c
>Copyright: 2019 Aaron Aaronson
>License: AAA
>
>Files: b.c
>Copyright: 2019 Belinda Bloggs
>License: BBB
>
>Files: c/h
>Copyright:
> 2010-2018 Aaron Aaronson
> 2016 Chris Cross
>License: CCC
>
>License: AAA
> You may do some things
>
>License: BBB
> You may do some other things
>
>License: CCC
> You may do different things
>
>into this less precise form?
>
>Format: imagine the correct URL is here
>Copyright:
> 2010-2019 Aaron Aaronson
> 2019 Belinda Bloggs
> 2016 Chris Cross
>License: AAA and BBB and CCC
>
>License: AAA
> You may do some things
>
>License: BBB
> You may do some other things
>
>License: CCC
> You may do different things
>
>(I haven't re-read the copyright format spec recently, so I don't know
>whether the spec actually allows this, and I don't know whether Lintian
>warns about it - but I feel as though it ought to be allowed.)
>
>> I think we should be optimising for reduced contributor time spent on
>> this task.
>
>I agree, but there's a limit to how far we can move in that direction
>without the ftp team clarifying their requirements.

I know for certain that the FTP Team has no requirements to use (or not) the 
DEP-5 format.  What the FTP Team needs is pretty orthogonal to using (or not) 
DEP-5.

Scott K



Re: Usage of DEP5

2019-11-08 Thread Russ Allbery
Simon McVittie  writes:

> into this less precise form?

> Format: imagine the correct URL is here
> Copyright:
>  2010-2019 Aaron Aaronson
>  2019 Belinda Bloggs
>  2016 Chris Cross
> License: AAA and BBB and CCC

> License: AAA
>  You may do some things

> License: BBB
>  You may do some other things

> License: CCC
>  You may do different things

> (I haven't re-read the copyright format spec recently, so I don't know
> whether the spec actually allows this, and I don't know whether Lintian
> warns about it - but I feel as though it ought to be allowed.)

It does, Lintian shouldn't warn, and yes, that's probably a smart idea for
most packages.  Note that Policy also now explicitly says that, if the
work involves significant time and effort, you don't need to collect
copyright notices unless the license requires that you preserve them,
which can also help.

> I agree, but there's a limit to how far we can move in that direction
> without the ftp team clarifying their requirements.

I would be very happy if someone on ftp-master would take on the project
of writing the Policy text for what needs to be included in
debian/copyright.  Attempts to clarify in the past usually turn into a
game of telephone.  It's really a policy set by and enforced by
ftp-master, so it would be awesome if that team would write it.

-- 
Russ Allbery (r...@debian.org)  



Re: Usage of DEP5

2019-11-08 Thread Simon McVittie
On Fri, 08 Nov 2019 at 10:51:45 -0700, Sean Whitton wrote:
> DEP-5 is the fastest way to write a d/copyright in some cases, but in
> others it is not.  Part of this is that DEP-5 somewhat encourages people
> to include more detail than is needed.

It would probably help if we had more clarity around what is needed: at
the moment the only way to know what is required is to upload to NEW and
see whether the package is accepted. Maintainers don't want their packages
to get additional delays from NEW rejection, so they have to err on the
side of including everything that the ftp team might possibly require.

Omitting the license grant (#904729, which is blocked on ftp team
feedback) would be one good way to reduce the amount of boilerplate
we're pasting into the copyright file.

If the per-file copyright information is something that is encouraged
by DEP-5 but not strictly needed: perhaps it would be viable to suggest,
or even encourage, changing this:

Format: imagine the correct URL is here

Files: a.c a.h aaa.c
Copyright: 2019 Aaron Aaronson
License: AAA

Files: b.c
Copyright: 2019 Belinda Bloggs
License: BBB

Files: c/h
Copyright:
 2010-2018 Aaron Aaronson
 2016 Chris Cross
License: CCC

License: AAA
 You may do some things

License: BBB
 You may do some other things

License: CCC
 You may do different things

into this less precise form?

Format: imagine the correct URL is here
Copyright:
 2010-2019 Aaron Aaronson
 2019 Belinda Bloggs
 2016 Chris Cross
License: AAA and BBB and CCC

License: AAA
 You may do some things

License: BBB
 You may do some other things

License: CCC
 You may do different things

(I haven't re-read the copyright format spec recently, so I don't know
whether the spec actually allows this, and I don't know whether Lintian
warns about it - but I feel as though it ought to be allowed.)

> I think we should be optimising for reduced contributor time spent on
> this task.

I agree, but there's a limit to how far we can move in that direction
without the ftp team clarifying their requirements.

smcv



Re: Usage of DEP5

2019-11-08 Thread Sean Whitton
Hello,

On Thu 07 Nov 2019 at 01:36AM -05, Scott Kitterman wrote:

> Although I use it for simple packages, for complex ones I think it makes
> debian/copyright maintenance much harder (many more things to get wrong).
> It's totally optional and should absolutely stay that way.
>
> The purpose of debian/copyright is to support license compliance.  Anything
> beyond that isn't relevant to its purpose within Debian.  While I recognize
> that the structured format has benefits for some people, I don't think it
> matters much within the project.

I agree with this assessment.

DEP-5 is the fastest way to write a d/copyright in some cases, but in
others it is not.  Part of this is that DEP-5 somewhat encourages people
to include more detail than is needed.

I think we should be optimising for reduced contributor time spent on
this task.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Re: Usage of DEP5

2019-11-07 Thread Richard Laager
On 11/7/19 7:40 AM, Thorsten Glaser wrote:
> I also often deal in software which
> has more… flexibility than the DEP 5 format allows, or where it is
> plain simpler.

Would you be willing to share an example, at a minimum just the name of
the package?

-- 
Richard



Re: Usage of DEP5

2019-11-07 Thread Andreas Tille
On Thu, Nov 07, 2019 at 08:33:23AM +0100, Ole Streicher wrote:
> 
> @Andreas: Independently of how this goes for the Debian Policy,
> recommending DEP5 would be a good thing for the policies of Debian
> Science and friends (astro, med).

I have not checked but I'd say every Debian Med package has DEP5 format.
When I'm touching any Debian Science package for whatever reason I'm
also converting d/copyright to DEP5.

> This could even allow to display the
> (source) license(s) on the blends web pages.

On the Blends web pages the prospective packages in Git have a license
field (see for example med-bio task[1]).  (I'm just realising that the
packages in new queue show "License: unknown" which is probably a bug
in the web sentinel code.)

The machine readable gatherer is parsing d/copyright if it is DEP5
formated - so I'm quite picky about this.

Kind regards

 Andreas.

[1] https://blends.debian.org/med/tasks/bio#pkgvcs-debs

-- 
http://fam-tille.de



Re: Usage of DEP5

2019-11-07 Thread Thorsten Glaser
Andreas Tille dixit:

>explicit wish to not use DEP5.  I wonder what other reasons might exist
>to explicitly stick to the non-machine readable format.

I prefer human-readable format. I also often deal in software which
has more… flexibility than the DEP 5 format allows, or where it is
plain simpler.

To make it clear, I also have packages with machine-readable format,
it’s not general but case-by-case, whichever suits better for the
situation.

The machine-readable format applies to the source tree, not the
binary packages, though, which makes it hard to impossible to map
some real-world scenatios involving heterogenous licences (differing
between binary packages, or different licences chosen of dual-licences,
or different binary package content depending on… things).

I have no problem with it in general, as long as it’s not forced.
It’s clearly a 90%+ solution, not a 100% solution.

If forcing machine-readable copyright is required for UMEGAYA,
then I’m sorry to say I will be removing debian/upstream/metadata
from some of my packages rather.

bye,
//mirabilos
-- 
 Beware of ritual lest you forget the meaning behind it.
 yeah but it means if you really care about something, don't
ritualise it, or you will lose it. don't fetishise it, don't
obsess. or you'll forget why you love it in the first place.



Re: Usage of DEP5

2019-11-07 Thread Mo Zhou
On Thu, Nov 07, 2019 at 08:33:23AM +0100, Ole Streicher wrote:
> Andreas Tille  writes:
> > I would love to see another discussion here to reach more uniformity in
> > Debian packaging and rise importance of DEP5 by recommending it in
> > Debian Policy.
> 
> I would really support that. A recommendation does not mean that there
> may be some exceptional cases where DEP5 is not applicable, although I
> think that DEP5 is flexible enough to cope with almost all cases.

+1. Only with machine readable format do we have a chance for automation.



Re: Usage of DEP5

2019-11-06 Thread Ole Streicher
Andreas Tille  writes:
> I would love to see another discussion here to reach more uniformity in
> Debian packaging and rise importance of DEP5 by recommending it in
> Debian Policy.

I would really support that. A recommendation does not mean that there
may be some exceptional cases where DEP5 is not applicable, although I
think that DEP5 is flexible enough to cope with almost all cases.

It is always an advantage to follow standardized procedures as they make
the communication between us simpler and allow for standardized tools to
process them, inclusion in the UDD etc.

@Andreas: Independently of how this goes for the Debian Policy,
recommending DEP5 would be a good thing for the policies of Debian
Science and friends (astro, med). This could even allow to display the
(source) license(s) on the blends web pages.

Best regards

Ole



Re: Usage of DEP5

2019-11-06 Thread Russ Allbery
Andreas Tille  writes:

> I admit I'm astonished about this.  From my point of view DEP5 was
> decided to be good packaging practice and I assumed that not changing to
> DEP5 would be a matter of "not important for me to spent my time on a
> DEP5 conversion".  However, I'm reading Thorstens statement as an
> explicit wish to not use DEP5.  I wonder what other reasons might exist
> to explicitly stick to the non-machine readable format.

There are some types of debian/copyright files that are kind of annoying
to express in the machine-readable format, mostly because the copyright
state requires some discussion or is easier to express as free-form text.
I think most of those cases have reasonable solutions with some work, but
it's quite a bit more work than adding an upstream metadata file.

This seems like a fairly marginal case, and I don't have a strong opinion
about the wiki comment, but we've talked about making machine-readable
copyright more strongly encouraged from time to time and there are always
objections from folks who are still not convinced it solves any problems
for them and who find it harder to work with for whatever reason.

-- 
Russ Allbery (r...@debian.org)  



Re: Usage of DEP5

2019-11-06 Thread Scott Kitterman
On Thursday, November 7, 2019 1:26:42 AM EST Andreas Tille wrote:
> Hi,
> 
> in a change to UpstreamMetadata in Wiki[1] Thorsten Glaser wrote:
> 
>These fields must still be allowed, as not all packagers wish to use DEP
> 5.
> 
> I admit I'm astonished about this.  From my point of view DEP5 was
> decided to be good packaging practice and I assumed that not changing to
> DEP5 would be a matter of "not important for me to spent my time on a
> DEP5 conversion".  However, I'm reading Thorstens statement as an
> explicit wish to not use DEP5.  I wonder what other reasons might exist
> to explicitly stick to the non-machine readable format.
> 
> I would love to see another discussion here to reach more uniformity in
> Debian packaging and rise importance of DEP5 by recommending it in
> Debian Policy.
> 
> Kind regards
> 
>   Andreas.
> 
> [1] https://wiki.debian.org/UpstreamMetadata?action=diff&rev1=134&rev2=135

Although I use it for simple packages, for complex ones I think it makes 
debian/copyright maintenance much harder (many more things to get wrong).  
It's totally optional and should absolutely stay that way.  

The purpose of debian/copyright is to support license compliance.  Anything 
beyond that isn't relevant to its purpose within Debian.  While I recognize 
that the structured format has benefits for some people, I don't think it 
matters much within the project.

Let's stick to making rules we actually need.

Scott K


signature.asc
Description: This is a digitally signed message part.


Usage of DEP5

2019-11-06 Thread Andreas Tille
Hi,

in a change to UpstreamMetadata in Wiki[1] Thorsten Glaser wrote:

   These fields must still be allowed, as not all packagers wish to use DEP 5.

I admit I'm astonished about this.  From my point of view DEP5 was
decided to be good packaging practice and I assumed that not changing to
DEP5 would be a matter of "not important for me to spent my time on a
DEP5 conversion".  However, I'm reading Thorstens statement as an
explicit wish to not use DEP5.  I wonder what other reasons might exist
to explicitly stick to the non-machine readable format.

I would love to see another discussion here to reach more uniformity in
Debian packaging and rise importance of DEP5 by recommending it in
Debian Policy.

Kind regards

  Andreas.

[1] https://wiki.debian.org/UpstreamMetadata?action=diff&rev1=134&rev2=135

-- 
http://fam-tille.de