Re: DEP5: non-DFSG repackaging documentation
On ke, 2010-09-15 at 09:45 +0100, Lars Wirzenius wrote: Good point about debian/watch. The simplest proposal right now is to make the Source field free-form text, and since I like simplicity, I support this. More detailed specification for documenting mechanical rules of transformations could wait until there's real experience of using this spec in the real world for this. Anyone opposed? Nobody opposed, so I applied the attached patch. === modified file 'dep5.mdwn' --- dep5.mdwn 2010-09-22 15:55:18 + +++ dep5.mdwn 2010-09-22 16:05:28 + @@ -142,10 +142,12 @@ will usually be written as a list of RFC2822 addresses or URIs. * **`Source`** - * Optional - * Syntax: line based list - * One or more URIs, indicating the primary - points of distribution of the software. + * Required + * Syntax: formatted text, no synopsis + * An explanation from where the upstream source came from. + Typically this would be a URL, but it might be a free-form + explanation. If the upstream source has been modified to remove + non-free parts, that should be explained in this field. * **`Disclaimer`** * Optional
Re: DEP5: non-DFSG repackaging documentation
On ti, 2010-09-14 at 17:35 -0700, Russ Allbery wrote: Jonas Smedegaard d...@jones.dk writes: Makes sense to me. Let's define only a single free-form field in the header section now. I suggest it then be a field specifically for notes regarding source not being pristine in the sense that the form as redistributed by Debian is different from how it was distributed by upstream. With this I mean that it should *both* cover cases of repackaging a tarball *and* generating a tarball from e.g. a checkout from an upstream VCS. Suggested filed name: Source-Repackaged-Reason: We already have a field for this purpose, namely Source. The only reason why we can't use it is because it's currently only allowed to contain URLs. So what about, instead, broadening the syntax of Source to say that it contains *either* a space-separated list of URLs for the simple case of reusing an upstream release tarball available from some URL *or* freeform text describing where the source came from. I don't think it's horribly important that the URLs in Source be machine-extractable, since that purpose is already served well by debian/watch. The field is primarily meant for humans anyway. Good point about debian/watch. The simplest proposal right now is to make the Source field free-form text, and since I like simplicity, I support this. More detailed specification for documenting mechanical rules of transformations could wait until there's real experience of using this spec in the real world for this. Anyone opposed? -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1284540328.2573.65.ca...@havelock
Debian training and code review
On ke, 2010-09-15 at 10:22 +0200, Joerg Jaspert wrote: I, using my FTPMaster hat, do care a lot that we do not get $whateveritsname with upload rights that never ever had to show at least the basic understanding of packaging work. Looking at all the errors existing Developers do, even longstanding ones, having something like TS drop away entirely will be near death. Whoever thinks it cant be that bad should do a month of release team, qa or ftpteam work. You will think different. This reminds me: it would be good to improve not just the quality of our packages, but our developers. Developing a Linux distribution involves a lot of skills, and stuff keeps changing all the time. It would perhaps be a good idea to have training sessions within Debian. At the moment, pretty much all training is handled by each developer themselves: they read documentation, or source, and experiment with things. They might write some blog posts, or mail a list, or something. This often works, but I'm sure we can do better. Ubuntu has developer weeks, where various people give hour-long IRC training sessions on various topics. We could join them, or have our own. Or we could have ad-hoc training sessions, like Debian-Women has done, and and is starting to do again. In addition to training, some collaborative code review might be helpful. debian-mentors is one good place for that, and asking on IRC on #debian-devel would work too. What do others think? -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1284541176.2573.77.ca...@havelock
Re: DEP5: X-Autobuild
On ke, 2010-09-15 at 17:38 +0200, Marc 'HE' Brockschmidt wrote: This is only about the field in debian/copyright, not about the field in debian/control. We don't need the former, only the latter. In that case I'll remove the X-Autobuild stuff from the DEP5 draft. Thanks. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1284571564.2573.84.ca...@havelock
Re: DEP5: non-DFSG repackaging documentation
On ma, 2010-09-13 at 14:54 -0700, Russ Allbery wrote: There should still be an explanation in debian/copyright of what that script does, since that's the Policy-required location for specifying where the upstream source came from. Oh, I thought only devref was requiring that to be in debian/copyright, not policy. In that case, I need to change my opinion. I would still like to avoid a whole mini-language in debian/copyright for documenting the transformation. A free-form text (perhaps in Disclaimer?) should suffice, I guess. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1284465211.2573.42.ca...@havelock
Re: DEP5: non-DFSG repackaging documentation
On ti, 2010-09-14 at 00:07 +0100, Stuart Prescott wrote: Personally, I'd like a nice machine-readable list of files/dirs/globs that should be removed from the tarball. I'd like it to be kept in a canonical location in the source tarball (debian/copyright, perhaps?) This all sounds good, with the exception that I'd rather not have the list in debian/copyright. More importantly, though, I suspect it may be the wrong time to specify this in DEP5, and it would be better to finish DEP5 first, and then, when someone writes the tool, to amend DEP5 accordingly, when there's enough experience to see that the tool works well in the majority of cases. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1284465448.2573.45.ca...@havelock
Re: DEP-5: Files field and filename patterns
On ti, 2010-09-07 at 06:24 +0100, Lars Wirzenius wrote: Nobody has commented on this in any way, so I assume I am still perfect and everything I say is flawless. I am attaching a proposed patch to rewrite the filename pattern section. Unless there are objections within a couple of days, I will push it out. That took more than a couple of days, but I've now merged the changes and pushed them out to the bzr trunk. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1284385633.2308.36.ca...@havelock
DEP5: Making Files: * non-optional
The current DEP5 draft says: * **`Files`** * Required for all but the first paragraph. If omitted from the first paragraph, this is equivalent to a value of '*'. * Syntax: white space separated list * List of patterns indicating files covered by the license and copyright specified in this paragraph. See File patterns below. Does anyone oppose if I remove the If omitted... sentence? I see no reason to make the format unnecessarily complicated by having it optional. In other words, I propose to make the Files: field mandatory in all paragraphs except the first (header) one, where it is not allowed at all. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1284386027.2308.39.ca...@havelock
DEP5: X-Autobuild
The current DEP5 draft has this paragraph: For a ''non-free'' package to be autobuilt, `debian/copyright` must contain an explanation that autobuilding is not forbidden (see [20061129152824.gt2...@mails.so.argh.org](http://lists.debian.org/msgid-search/2 0061129152824.gt2...@mails.so.argh.org)). It is proposed to use an extra field in the header, with name **`X-Autobuild`**, that would contain `yes` in the first line and the explanation in the others. Is this a good way of doing that? The referred-to e-mail says that an XS-Autobuild header in the debian/control (not copyright) file is required. Is there a need for a particular header for this in debian/copyright? Would not the Disclaimer field be sufficient? I propose to remove the entire paragraph. If the consensus is against that, I propose we rename the field to Non-Free-Autobuild instead of using an X- prefix. Opinions? -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1284386312.2308.44.ca...@havelock
DEP5: non-DFSG repackaging documentation
From the DEP5 wiki page: Dev-ref §6.7.8.2 recommends that if you have to repackage the original source, that the transformations that are performed be recorded in debian/copyright. While there was recently some discussion on d-devel about whether repackaging just to remove distributable-but-not-dfsg-free material was worth it or not, the case where a source tarball contains non-distributable material still must be dealt with. A field to express what was done would thus fit well with this recommendation. Further discussion as to whether it should/could be a find -delete command, a see README.Debian-source comment or some simple description of what was done (e.g. copy of rfc removed) is sensible. What was done as well as why it was done should probably be included. My opinions: - if the transformation can be expressed as a script, use debian/rules get-orig-source - otherwise, debian/README.Source seems like a better place to document this than debian/copyright, since it has other instructions for creating the source package, too Thus I would prefer it if DEP5 was silent on this, and Dev-ref would be changed to point to get-orig-source and README.Source instead. Opinions? -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1284386580.2308.48.ca...@havelock
Re: DEP-5: Files field and filename patterns
On ma, 2010-09-13 at 23:22 +0900, Charles Plessy wrote: Le Mon, Sep 13, 2010 at 02:47:13PM +0100, Lars Wirzenius a écrit : That took more than a couple of days, but I've now merged the changes and pushed them out to the bzr trunk. Hi Lars, and bzr experts, I do not know what happened, but the dep bzr repository is not visible anymore through the loggerhead web interface :( http://bzr.debian.org/loggerhead/dep/dep5/trunk/files (now broken) http://bzr.debian.org/loggerhead/ (no dep) I have no idea what happened. Please report this to the bzr.debian.org admins. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1284397007.2308.50.ca...@havelock
Re: DEP5: non-DFSG repackaging documentation
On ma, 2010-09-13 at 16:58 +0200, Jonas Smedegaard wrote: It makes good sense to me that we (continue to) track stripped files at the same place as distributed files. On the other hand, I don't see the point of using debian/copyright to document copyright information of files that are not part of the source package. Currently I maintain 2 lists of stripped files: in debian/copyright (where the - most often legal - reason is needed) and debian/rules (for use by the get-orig-source rule). Moving the information to debian/README.source would loose the ability to use it in scripts. Like I said, if it is scripted, I believe it belongs in debian/rules, and only there. If it isn't scripted. README.source seems to me to be ideal. If we do put the stripping information into debian/copyright, can someone please suggest a concrete way to actually do that? What is actually needed to implement the stripping automatically in get-orig-source? -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1284397512.2308.55.ca...@havelock
Re: DEP5: Making Files: * non-optional
On ma, 2010-09-13 at 09:06 -0700, Manoj Srivastava wrote: Currently, one only needs to list the copyrights in the package, without specifying which file each copyright applies to. How is that specified in DEP5 format? Implying that all copyright notices apply to all files would be an untruth. (Or are we expanding the requirements for copyright files to map copyright notices to files in the source package?) There is a consensus, as far as I can see, to allow the first (header) paragraph to have Copyright and License fields that will apply to the package as a whole, rather than to each file. This is an upcoming change that is in the pipeline (but I don't want to make all changes at once). I would suggest that a missing files: field in the headers implies that no statement is being made about which files the copyright notice applies to, instead f implying it applies to all files. On the other hand, this means a paragraph where the Files field is missing by mistake will be interpreted wrongly. I find putting the information in the header paragraph to be cleaner, but I admit it is a subtle point. It's better to be explicit when possible, to allow errors to be noticed easier. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1284397783.2308.58.ca...@havelock
Re: DEP-5: Ack section
On ti, 2010-09-07 at 13:28 +0200, Jonas Smedegaard wrote: Do anyone else feel that I should be mentioned? I do. Added. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1283921454.12945.10.ca...@havelock
Re: DEP-5: Ack section
On ti, 2010-08-31 at 11:10 +0200, Bernd Zeimetz wrote: + Larz Wirzenius Don't forgot yourself! :) Done. If anyone remembers anyone else who should be added, please tell me, and I'll add them. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1283834942.2264.31.ca...@havelock
Re: DEP-5: Files field and filename patterns
On la, 2010-08-28 at 19:51 +1200, Lars Wirzenius wrote: To make this go forward, I suggest that we adopt Charles's suggestion of very simple globbing, since that's going to be compatible with more powerful syntaxes if we want to adopt those later. Further, I suggest we not treat the slash character specially when matching, so that */Makefile.in will match Makefile.in at any depth. All patterns are anchored to the root of the source tree; thus a plain Makefile.in will match only at the root of the source tree. I suggest we not add exclusions at this time. In a year or two, we can re-visit this part of the spec and see if it needs to be improved. Is this proposal acceptable? Nobody has commented on this in any way, so I assume I am still perfect and everything I say is flawless. I am attaching a proposed patch to rewrite the filename pattern section. Unless there are objections within a couple of days, I will push it out. === modified file 'dep5.mdwn' --- dep5.mdwn 2010-08-31 21:08:28 + +++ dep5.mdwn 2010-09-07 05:22:34 + @@ -276,62 +276,59 @@ Extra fields can be added to any section. Their name starts by **`X-`**. ## Fields Detail + ### Files - Format -The **`Files`** field contains a list of comma-separated patterns - - Files: foo.c, bar.*, baz.[ch] - -File names containing spaces or commas should be put within double -quotes. The backslash character is an escaping character, be it inside -or outside double quotes: - - Files: Program Files/*, manual[english].txt - - Syntax -Patterns are handled as by the `find` utility's `-name` option. Patterns -containing a path separator (/) are handled as by the `find` utility's -`-path` option. - -The following matches all `Makefile.am` files in the tree and all -Python scripts: - - Files: */Makefile.am, *.py - -But this will only match the top-level `Makefile.am`: - - Files: ./Makefile.am - -For the first example, the equivalent `find` command would be: - - find . -path */Makefile.am -o -name *.py - -It is quite common for a work to have files with copyright held by -different parties and received under different licenses. To accommodate -this, **multiple paragraphs are allowed with different `Files` -declarations**. - -However it makes for easier reading if the copyright file lists the -main license first: the one matching the top level of the work, with -others listed as exceptions. To allow this, the following precedence -rule applies for matching files: **If multiple `Files` declarations -match the same file, then only the last match counts.** - -As a result, it is recommended for clarity that the paragraphs appear in -order from most general (e.g. `Files: *`) first, through to most -specific. In the following example, the file `getopt.c` matches both -`Files: *` and `Files: getopt.*`; only the last match counts, so -the file `getopt.c` has the license declaration `License: BSD`. - - Files: * - Copyright: 2003-2005, John Doe j...@xample.com - License: [the main work's license] - [LICENSE TEXT] - - Files: getopt.* - Copyright: 2000, The Corporation Foundation, Inc. - License: BSD - [LICENSE TEXT] + +Filename patterns in the `Files` field are specified using a +simplified shell glob syntax. Patterns are separated by +white space. + +* Only the wildcards `*` and `?` apply; the former matches any number + of characters (including none), the latter a single character. Both + match a slash (`/`) and a leading dot. +* The backslash (`\\`) is used to remove the magic from the next + character; see table below. +* Patterns match pathnames that start at the root of the source tree. + Thus, `Makefile.in` matches only the file at the root of the tree, + but `*/Makefile.in` matches at any depth. + +Backslash escape sequences: + +\* match star (asterisk) +\? match question mark +\\ match backslash + +Any other character following a backslash is an error. + +Multiple `Files` paragraphs are allowed. The last paragraph that +matches a particular file applies to it. + +Exclusions are done by having multiple `Files` paragraphs. + +Example: + +Files: * +Copyright: 1975-2010 Ulla Upstream +License: GPL2+ + +Files: debian/* +Copyright: 2010 Daniela Debianizer +License: GPL2+ + +Files: debian/patches/fancy-feature +Copyright: 2010 Daniela Debianizer +License: GPL3+ + +Files: */*.1 +Copyright: 2010 Manuela Manpager +License: GPL2+ + +In this example, all files are copyright by the upstream and licensed +under the GPL, version 2 or later, with three exceptions. +All the Debian packaging files are copyright by the packager, +and further one specific file providing a new feature is licensed +differently. Finally, there are some manual pages added to the package, +written by a third person. ### License Short name
DEP5: Editorial changes
I propose the attached patch to make some editorial changes to DEP5. A summary of the changes is below. I believe these should be uncontroversial and that they do not change the meaning of the spec, but do make it easier to read and edit. If nobody objects, I'll apply and push this in a day or two. Later objections are OK, they just mean I will revert all or some of this. Remove paragraph repeating information from earlier in the document. Make all examples be indented by 4 spaces, not 8. Rename section to paragraph, for consistency. Expand tabs to 4 spaces. Add a link to policy. Get rid of pointless double backquotes. Fold sub-bullet for Copyright into main description. Remove Copyright example. Remove second example, as it does not add anything. Remove 'On Debian systems'. Simplify description of Upstream-Contact. Simplify description of Upstream-Name. Change 'Value:' prefix to 'Syntax:' prefix. Remove 'Syntax:' prefix from field descriptions. Replace multple single occurence with a note in the general file syntax section. === modified file 'dep5.mdwn' --- dep5.mdwn 2010-08-31 21:08:28 + +++ dep5.mdwn 2010-09-07 05:46:26 + @@ -1,20 +1,20 @@ [[!meta title=DEP-5: Machine-readable debian/copyright]] - Title: Machine-readable debian/copyright - DEP: 5 - State: DRAFT - Date: 2010-08-23 - Drivers: Steve Langasek vor...@debian.org, - Lars Wirzenius l...@liw.fi - URL: http://dep.debian.net/deps/dep5 - License: - Copying and distribution of this file, with or without modification, - are permitted in any medium without royalty provided the copyright - notice and this notice are preserved. - Abstract: - Establish a standard, machine-readable format for debian/copyright - files within packages, to facilitate automated checking and - reporting of licenses for packages and sets of packages. +Title: Machine-readable debian/copyright +DEP: 5 +State: DRAFT +Date: 2010-08-23 +Drivers: Steve Langasek vor...@debian.org, + Lars Wirzenius l...@liw.fi +URL: http://dep.debian.net/deps/dep5 +License: + Copying and distribution of this file, with or without modification, + are permitted in any medium without royalty provided the copyright + notice and this notice are preserved. +Abstract: + Establish a standard, machine-readable format for debian/copyright + files within packages, to facilitate automated checking and + reporting of licenses for packages and sets of packages. [[!toc ]] @@ -113,15 +113,16 @@ For example, `Disclaimer` has no special first line, whereas `License` does. +Each field may occur at most once in a paragraph. + # Implementation -## Sections -### Header Section (Once) +## Paragraps +### Header paragraph (Once) * **`Format`** * Required - * Single occurrence - * Value: single line - * Syntax: URI of the format specification, such as: + * Syntax: single line + * URI of the format specification, such as: * http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=filerev=REVISION * Note that the unwieldy length of the URL should be solved in future by hosting the specification at a shorter URL (including the @@ -129,39 +130,33 @@ * **`Upstream-Name`** * Optional - * Single occurrence - * Value: single line - * Syntax: Single line (in most cases a single word), - containing the name upstream uses for the software. + * Syntax: single line + * The name upstream uses for the software. * **`Upstream-Contact`** * Optional - * Single occurrence - * Value: line based list - * Syntax: Line(s) containing the preferred address(es) to reach + * Syntax: line based list + * The preferred address(es) to reach the upstream project. May be free-form text, but by convention will usually be written as a list of RFC2822 addresses or URIs. * **`Source`** * Optional - * Single occurrence - * Value: line based list - * Syntax: One or more URIs, indicating the primary + * Syntax: line based list + * One or more URIs, indicating the primary points of distribution of the software. * **`Disclaimer`** * Optional - * Single occurrence - * Value: formatted text, no synopsis - * Syntax: On Debian systems, this field can be + * Syntax: formatted text, no synopsis + * This field can be used in the case of non-free and contrib packages (see [Policy 12.5]( http://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile)) * **`Comment`** * Optional - * Single occurrence per paragraph, can occur in each paragraph. - * Value: formatted text, no synopsis + * Syntax: formatted text, no synopsis * Description: This field can provide additional information. For example, it might quote an e-mail from upstream justifying why the license is acceptable to the main archive, or @@ -169,19 +164,14 @@ from a version known to be DFSG-free, even though the current upstream version
Re: Upstream guide and front desk
On ke, 2010-09-01 at 19:27 +0300, Andrei Popescu wrote: Unless you consider it's necessary to be a DD for this I could join as well. After all, I spend *a lot* of time reading Debian mailing lists and I have become familiar with a lot of processes. It's time I put this to some good use :-) I see no reason to restrict this to DDs only. It should be a public list, with public archives. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1283375638.14666.9.ca...@havelock
Re: DEP-5: Files field and filename patterns
On to, 2010-08-26 at 08:43 +1200, Lars Wirzenius wrote: The Files field needs to specify patterns on filenames. We need to specify how to do that. Here is my understanding of the current situation: * There is no particular consensus on filename patterns. * Charles suggests a very simple globbing (* and ? and nothing else). * .gitignore is still on the table, but has neither strong support, nor strong opposition. * No consensus on exclusions in patterns versus multiple paragraphs. * No consensus on patterns on basename only, versus the whole path. * Nobody seems to object dropping commas for separating patterns. * Nobody likes my idea of regexps on pathnames. To make this go forward, I suggest that we adopt Charles's suggestion of very simple globbing, since that's going to be compatible with more powerful syntaxes if we want to adopt those later. Further, I suggest we not treat the slash character specially when matching, so that */Makefile.in will match Makefile.in at any depth. All patterns are anchored to the root of the source tree; thus a plain Makefile.in will match only at the root of the source tree. I suggest we not add exclusions at this time. In a year or two, we can re-visit this part of the spec and see if it needs to be improved. Is this proposal acceptable? If so, I'll write up a formal suggestion for the new wording. (I'm sitting in a cafe waiting for a movie to start, so I don't have time for that now.) (Burglars please take note: we've emptied our apartment. We're moving to another country. There's no point in trying to steal anything, unless you like carpet lint.) (Oh, people following the DEP-5 saga should perhaps note that for the next week I'll be in transit and might not have frequent Internet access. Indeed, I might be entirely too busy avoiding dropbears, boxing with kangaroos, and learning life lessons from koalas to react very quickly to DEP-5 e-mails, but I'll get to them the following week.) (Lisp programmers please take note: I am not saying using Lisp will make you use too many parentheses, but that's certainly what happened to me.) -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1282981875.2242.136.ca...@havelock
DEP-5: No alternative syntaxes
I have just committed the change below to disallow alternative syntaxes for DEP-5, since having, say, YAML in addition to RFC-822 style headers is silly. I did not discuss this beforehand since I do not expect anyone objecting to it at this stage of the DEP. It might have been relevant early on in the development of the format to consider other formats. If anyone objects, please raise the issue and I will revert the change until the discussion is over and an explicit consensus is well-known. === modified file 'dep5.mdwn' --- dep5.mdwn 2010-08-25 21:31:21 + +++ dep5.mdwn 2010-08-29 03:37:01 + @@ -514,9 +514,6 @@ ## Implementation -It is proposed to implement this proposal in pseudo-RFC-822 format (the one of -debian/control). However, other syntaxes could be used, such as YAML. - ### Examples in pseudo-RFC-822 format Simple A possible `copyright` file for the program 'X Solitaire' distributed in the -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1283053199.2242.207.ca...@havelock
DEP-5: Ack section
Given the large number of people who have worked on DEP-5 over the years, a section acknowledging their work would be a good idea, I think. Below is a start of one. Could someone who's been involved with this longer than I have make a list of missing people? === modified file 'dep5.mdwn' --- dep5.mdwn 2010-08-29 03:37:28 + +++ dep5.mdwn 2010-08-29 03:44:45 + @@ -58,6 +58,18 @@ they have a problem with, even if the licenses are DFSG-free. For example, the Affero GPL. +# Acknowledgements + +Many people have worked on this specification over the years. +The following alphabetical list is incomplete, +please suggest missing people: +Russ Allbery, +Ben Finney, +Sam Hocevar, +Steve Langasek, +Charles Plessy, +Noah Slater. + # File syntax The `debian/copyright` file must be machine-interpretable, yet -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1283053617.2242.209.ca...@havelock
Re: DEP-5: general file syntax
On ma, 2010-08-23 at 14:50 +1200, Lars Wirzenius wrote: On su, 2010-08-22 at 15:24 -0700, Russ Allbery wrote: It's... okay. It's a little strange, but I don't think it would be confusing since it is a summary of the license text in a machine-readable format, in essence. ACK, you and Ben have assured me that it is acceptable, and I've changed the spec draft. Latest diff attached. There hasn't been any further suggestions to this diff, so I'll apply it to the bzr trunk and we can move to the next topic. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1282767798.2242.22.ca...@havelock
Re: DEP-5: Comment field
On ke, 2010-08-25 at 14:07 -0700, Russ Allbery wrote: Looks fine to me, although as a very minor point I'd replace Debian ftpmaster team with upstream, since that's the more typical case. Fair enough. Done. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1282771904.2242.55.ca...@havelock
Re: DEP-5: Comment field
On to, 2010-08-26 at 09:21 +0900, Charles Plessy wrote: Common comments come on. Heh. - Will paragraphs that contain only a Comment field be valid ? Each paragraph is either a header (Format required), file license specification (Files required), or stand-alone license description (License required). I don't see a paragraph with only Comment being allowed, or necessary. - Is the purpose of the field to be displayed after parsing, or only to provide complements of information in the source file ? Display, of course, to the extend any of the fields are for display. - If we take the Policy strictly, comments lines starting by ‘#’ are only allowed in §5.2 (Source package control files -- debian/control), which we do not refer to in the DEP. Will the DEP also accept such comment lines ? I don't care, myself. As it stands, following a strict reading of the DEP-5 spec and policy, hash comments are not allowed in debian/copyright. I'm OK with that, personally. If someone wants to suggest wording to allow them, please do, and unless there's opposition, I'll add that to the spec. However, given my extreme amount of not caring, I don't want to spend the energy on this wording myself. :) Does anyone want hash comments to be allowed in debian/copyright? Are they useful? -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1282792697.2242.92.ca...@havelock
Re: DEP-5: Files field and filename patterns
On to, 2010-08-26 at 08:39 +0900, Charles Plessy wrote: Adding an exclusion syntax with ‘!’ has some use, but it would be to the expense of being able to paste the field's value, and between the two I prefer being able to paste. I, on the other hand, would prefer to have exclusion syntax, to make the job of the person writing the debian/copyright file easier, rather than the job of the person copy-pasting things out of it. What do others think? Is anyone else than Russ (and, maybe, me) in favor of .gitignore syntax? -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1282792799.2242.94.ca...@havelock
Re: DEP-5: general file syntax
On la, 2010-08-21 at 22:30 -0700, Manoj Srivastava wrote: Can't we just fold long copyright header fields similarly? The issue is that one Copyright field (or header) will contain many copyright statements, and if we want to automatically parse those, we need a way to see where a new one starts. However, since there seems to be no current plans to parse copyright statements out of the Copyright field, I think we can forget this issue, at least for now, and leave it for later generations to solve, if they start caring. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1282514128.12989.386.ca...@havelock
Re: DEP-5: general file syntax
On su, 2010-08-22 at 16:12 +0900, Charles Plessy wrote: I also feel a contradiction to call ‘free-form’ some text that is formatted according to some markup rules, even if they are simple. I propose to replace instances like: Free-form text formatted like package long descriptions by: Formatted text like package long descriptions ACK, done. All in all, I would recommend to make these fields free-form. Packaging teams that would like to use a more specialised syntax can add their own local policies on top of the DEP. I disagree with this: I think a line-based list is perfectly fine for Upstream-Contact. Does anyone else have an opinion? @@ -99,13 +132,15 @@ * **`Source`** * Optional * Single occurrence + * Value: single line * Syntax: One or more URIs, one per line, indicating the primary point of distribution of the software. Since the syntax allows multiple URIs, and since the URIs may be long, I think that allowing newlines in the field will make it more readable. for instance by making it free-form (not formatted, see below). Actually, I think I made a mistake: I think Source should be a line-based list. This will make it easier for parsers to extract the URIs. Splitting a URI to two physical lines seems to me a bad idea, and messes up URI parsing in too many contexts. (The real fix is to get upstream to not have excessively long URIs, but that's hard to fix.) If the extended description finally requires double space for verbatim display, then how abould calling the ‘special first line’ synopsis, to be closer to the vocabulary used in the specification of the Description field ? Could some English experts weigh in whether the word synopsis is a good way to describe the list of license short names? -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1282514846.12989.396.ca...@havelock
Re: DEP-5: general file syntax
I've attached the current diff for the general file syntax changes. === modified file 'dep5.mdwn' --- dep5.mdwn 2010-08-21 09:05:12 + +++ dep5.mdwn 2010-08-22 22:08:51 + @@ -76,7 +76,7 @@ * Single-line values. * White space separated lists. * Line based lists. -* Free-form text formatted like package long descriptions. +* Text formatted like package long descriptions. A single-line value means that the whole value of a field must fit on a single line. For example, the `Format` field has a single line value @@ -90,7 +90,7 @@ Another kind of list value has one value per line. For example, `Copyright` can list many copyright statements, one per line. -Free-form text is formatted the same as the long description in +Formatted text fields use the same rules as the long description in a package's `Description` field, possibly also using the first field in a special way, like `Description` uses it for the short description. @@ -132,14 +132,14 @@ * **`Source`** * Optional * Single occurrence - * Value: single line - * Syntax: One or more URIs, one per line, indicating the primary - point of distribution of the software. + * Value: line based list + * Syntax: One or more URIs, indicating the primary + points of distribution of the software. * **`Disclaimer`** * Optional * Single occurrence - * Value: free-form text, no special first line + * Value: formatted text, no special first line * Syntax: On Debian systems, this field can be used in the case of non-free and contrib packages (see [Policy 12.5]( @@ -183,7 +183,7 @@ * **`License`** * Licensing terms for the files listed in **`Files`** field for this section * Required - * Value: free-form text, with special first line + * Value: formatted text, with special first line * Syntax: * First line: an abbreviated name for the license (see *Short names* section for a list of standard abbreviations). If empty, it is
Re: DEP-5: general file syntax
On su, 2010-08-22 at 15:24 -0700, Russ Allbery wrote: It's... okay. It's a little strange, but I don't think it would be confusing since it is a summary of the license text in a machine-readable format, in essence. ACK, you and Ben have assured me that it is acceptable, and I've changed the spec draft. Latest diff attached. === modified file 'dep5.mdwn' --- dep5.mdwn 2010-08-17 20:47:26 + +++ dep5.mdwn 2010-08-23 02:47:59 + @@ -3,7 +3,7 @@ Title: Machine-readable debian/copyright DEP: 5 State: DRAFT - Date: 2010-08-18 + Date: 2010-08-23 Drivers: Steve Langasek vor...@debian.org, Lars Wirzenius l...@liw.fi URL: http://dep.debian.net/deps/dep5 @@ -70,6 +70,36 @@ http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-controlsyntax for details. +There are four kinds values for fields. Each field specifies which +kind is allowed. + +* Single-line values. +* White space separated lists. +* Line based lists. +* Text formatted like package long descriptions. + +A single-line value means that the whole value of a field must fit on +a single line. For example, the `Format` field has a single line value +specifying the version of the machine-readable format that is used. + +A white space separated list means that the field value may be on one +line or many, but values in the list are separated by one or more +white space characters (including space, TAB, and newline). For +example, the `Files` field has a list of filename patterns. + +Another kind of list value has one value per line. For example, +`Copyright` can list many copyright statements, one per line. + +Formatted text fields use the same rules as the long description in +a package's `Description` field, possibly also using the first +line as a synopsis, like `Description` uses it for the +short description. +See section 5.6.13, Description, at +http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Description +for details. +For example, `Disclaimer` has no special first line, whereas +`License` does. + # Implementation ## Sections ### Header Section (Once) @@ -77,6 +107,7 @@ * **`Format`** * Required * Single occurrence + * Value: single line * Syntax: URI of the format specification, such as: * http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=filerev=REVISION * Note that the unwieldy length of the URL should be solved in @@ -86,12 +117,14 @@ * **`Upstream-Name`** * Optional * Single occurrence + * Value: single line * Syntax: Single line (in most cases a single word), containing the name upstream uses for the software. * **`Upstream-Contact`** * Optional * Single occurrence + * Value: line based list * Syntax: Line(s) containing the preferred address(es) to reach the upstream project. May be free-form text, but by convention will usually be written as a list of RFC2822 addresses or URIs. @@ -99,13 +132,15 @@ * **`Source`** * Optional * Single occurrence - * Syntax: One or more URIs, one per line, indicating the primary - point of distribution of the software. + * Value: line based list + * Syntax: One or more URIs, indicating the primary + points of distribution of the software. * **`Disclaimer`** * Optional * Single occurrence - * Syntax: Free-form text. On Debian systems, this field can be + * Value: formatted text, no synopsis + * Syntax: On Debian systems, this field can be used in the case of non-free and contrib packages (see [Policy 12.5]( http://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile)) @@ -132,13 +167,15 @@ * Required for all but the first paragraph. If omitted from the first paragraph, this is equivalent to a value of '*'. + * Value: white space separated list * Syntax: List of patterns indicating files covered by the license and copyright specified in this paragraph. See File patterns below. * **`Copyright`** * Required - * Syntax: one or more free-form copyright statement(s) that apply to - the files matched by the above pattern. + * Value: line based list + * Syntax: one or more free-form copyright statement(s), one per line, + that apply to the files matched by the above pattern. * Example value: 2008, John Q. Holder john.hol...@example.org * If a work has no copyright holder (i.e., it is in the public domain), that information should be recorded here. @@ -146,6 +183,7 @@ * **`License`** * Licensing terms for the files listed in **`Files`** field for this section * Required + * Value: formatted text, with synopsis * Syntax: * First line: an abbreviated name for the license (see *Short names* section for a list of standard abbreviations). If empty, it is
Re: webchat/cgiirc on irc.debian.org
On su, 2010-08-22 at 23:36 -0300, Valessio S Brito wrote: The proposal is to have something similar to http://webchat.freenode.net/ Using cgiirc on webchat.debian.org or irc.debian.org or .net The one place I know that advertises a web IRC gateway is the Koha project (http://koha-community.org/). I asked on their IRC channel, and their experiences have been quite positive. The least sophisticated people are unlikely to have much experience IRC, and probably won't have an IRC client installed, so having a web IRC client will make it easier for them to get help. I'm afraid I have idea what it would take to set this up and operate it, though. Does a free software implementation exist? -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1282533528.12989.433.ca...@havelock
Re: [DEP5] [patch] Renaming the ‘Maintainer’ field ‘Contact’
On pe, 2010-08-20 at 16:52 -0700, Steve Langasek wrote: The fact that we're both expressing this in terms of preference means, I think, both that this doesn't meet Lars's wave of opposition standard and that we're not definitely in bikeshed territory. :) I support Lars in deciding this question one way or the other so we can move on. Well, this is hard. There's no clear consensus, so ideally we would continue discussion, but this is really a pretty small point, so I'll force a decision: I'll keep the Upstream-Contact and Upstream-Name fields in the spec. This will either let us move on to other things, or provoke a wave of opposition, giving me sufficient reason to remove them from the spec, and letting us move on to other things. (Machiavelli was my pupil. All that he wrote in his little booklet he learned from the masterly way I direct Debian discussions.) -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1282378642.12989.299.ca...@havelock
Re: DEP-5: general file syntax
On pe, 2010-08-20 at 17:05 -0700, Russ Allbery wrote: I think a better approach would be to, once the document has settled down, publish it with a version number and give that version of the document a permanent URL. So, for instance, we would publish DEP-5 1.0 and give it a URL something like http://dep.debian.net/DEP-5/1.0 at which it would always be found. If we publish a new version of the document, the new version would be put at http://dep.debian.net/DEP-5/1.1, but the old version wouldn't be changed. DEPs are not supposed to change after they're approved, so it should be a new DEP rather than DEP-5/1.1, but that's a trivial detail. How would that tie in with updating it via the normal policy process? I thought we'd keep the file in the debian-policy package for future updates. Note that you should say that explicitly, since in the control file format not every field is multi-line (the default is that a field may not be multi-line). ACK. I think we could merge all three of these into the same case by using the Description syntax, with the note that blank lines don't really make sense in some fields. (So, I guess, merge them into two cases.) I'm OK with saying that multiline fields should use the Description markup, especially noting Charles's point about only using the long description part, when appropriate. This simplifies things quite a lot. I'll word a concrete patch to propose. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1282379544.12989.309.ca...@havelock
Re: DEP-5: general file syntax
On la, 2010-08-21 at 20:32 +1200, Lars Wirzenius wrote: I'm OK with saying that multiline fields should use the Description markup, especially noting Charles's point about only using the long description part, when appropriate. This simplifies things quite a lot. I'll word a concrete patch to propose. While wording this, I realized that we have more cases: Files has a list of values (currently comma-separated, but I propose to make it white-space separated), and Copyright and maybe other fields have a list of values one per line. I took the liberty of taking this into account. The relevant new text in the file syntax section: There are four kinds values for fields. Each field specifies which kind is allowed. * Single-line values. * White space separated lists. * Line based lists. * Free-form text formatted like package long descriptions. A single-line value means that the whole value of a field must fit on a single line. For example, the `Format` field has a single line value specifying the version of the machine-readable format that is used. A white space separated list means that the field value may be on one line or many, but values in the list are separated by one or more white space characters (including space, TAB, and newline). For example, the `Files` field has a list of filename patterns. Another kind of list value has one value per line. For example, `Copyright` can list many copyright statements, one per line. Free-form text is formatted the same as the long description in a package's `Description` field, possibly also using the first field in a special way, like `Description` uses it for the short description. See section 5.6.13, Description, at http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Description for details. For example, `Disclaimer` has no special first line, whereas `License` does. I'm attaching the exact diff, which lists the type of value for each field. Comments? === modified file 'dep5.mdwn' --- dep5.mdwn 2010-08-17 20:47:26 + +++ dep5.mdwn 2010-08-21 09:04:06 + @@ -70,6 +70,36 @@ http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-controlsyntax for details. +There are four kinds values for fields. Each field specifies which +kind is allowed. + +* Single-line values. +* White space separated lists. +* Line based lists. +* Free-form text formatted like package long descriptions. + +A single-line value means that the whole value of a field must fit on +a single line. For example, the `Format` field has a single line value +specifying the version of the machine-readable format that is used. + +A white space separated list means that the field value may be on one +line or many, but values in the list are separated by one or more +white space characters (including space, TAB, and newline). For +example, the `Files` field has a list of filename patterns. + +Another kind of list value has one value per line. For example, +`Copyright` can list many copyright statements, one per line. + +Free-form text is formatted the same as the long description in +a package's `Description` field, possibly also using the first +field in a special way, like `Description` uses it for the +short description. +See section 5.6.13, Description, at +http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Description +for details. +For example, `Disclaimer` has no special first line, whereas +`License` does. + # Implementation ## Sections ### Header Section (Once) @@ -77,6 +107,7 @@ * **`Format`** * Required * Single occurrence + * Value: single line * Syntax: URI of the format specification, such as: * http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=filerev=REVISION * Note that the unwieldy length of the URL should be solved in @@ -86,12 +117,14 @@ * **`Upstream-Name`** * Optional * Single occurrence + * Value: single line * Syntax: Single line (in most cases a single word), containing the name upstream uses for the software. * **`Upstream-Contact`** * Optional * Single occurrence + * Value: line based list * Syntax: Line(s) containing the preferred address(es) to reach the upstream project. May be free-form text, but by convention will usually be written as a list of RFC2822 addresses or URIs. @@ -99,13 +132,15 @@ * **`Source`** * Optional * Single occurrence + * Value: single line * Syntax: One or more URIs, one per line, indicating the primary point of distribution of the software. * **`Disclaimer`** * Optional * Single occurrence - * Syntax: Free-form text. On Debian systems, this field can be + * Value: free-form text, no special first line + * Syntax: On Debian systems, this field
Re: DEP-5: general file syntax
On la, 2010-08-21 at 01:58 -0700, Russ Allbery wrote: How would that tie in with updating it via the normal policy process? I thought we'd keep the file in the debian-policy package for future updates. I was assuming that's how we'd get to a 1.1 version. I haven't read DEP-0 recently, though, so I guess I have a poor grasp of how this is supposed to work. I'll go review it. If we pick up the files in debian-policy, then wherever we publish them from should really publish the versions from the debian-policy package. I was assuming we'd have the current official version be in the debian-policy package, and published at http://www.debian.org/doc/ or http://www.debian.org/doc/debian-policy/ rather than on dep.debian.net. The final version of DEP-5 would have a pointer to the version in debian-policy. That's why I'm having such as bad time figuring out how to put the version in the URL. However, it now strikes me that the filename in debian-policy can just have the version number. So the filename would start out as copyright-format-1.0.txt, and when it changes, the the filename changes to copyright-format-1.1.txt. Does that sound reasonable? The URL for Format would then be something like http://www.debian.org/doc/packaging-manuals/copyright-format-1.0.html That's a bit long, perhaps. Having an updated DEP-5 be generated from debian-policy on dep.debian.net, when DEP is not used to update it, seems unpleasantly complicated to me. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1282382283.12989.320.ca...@havelock
Re: DEP-5: general file syntax
On la, 2010-08-21 at 02:15 -0700, Russ Allbery wrote: What happens when the copyright statement is longer than a line? I have a bunch of those, such as: Good point. I see at least thw following possible solutions: * Keep one line per copyright statement, but make the lines be long. (This is what we have now.) * Have one copyright statement per Copyright field, and have multiple instances of the field. * Just make it all be free-form text, disabling any automatic parsing of the Copyright field. Note that the FSF lawyer told them not to use ranges in copyright dates, For actively maintained software, this is going to get really hard to read in a millennium or two. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1282382607.12989.324.ca...@havelock
Re: Upstream guide and front desk
On la, 2010-08-21 at 15:47 +0300, George Danchev wrote: I just wonder what this list would be meant to serves which can't be deemed suitable for -mentors. Many upstreams (regardless they have any preliminary packages of their software or not) already use -mentors for entering Debian one way or another. It might be that too much separation might accidently introduce some confusion amongst the targeted consumers. I'm not opposing to a yet another mailing list per se, so please decipher that more like a question, rather than objection. debian-mentors is an excellent list for an upstream to participate in if they have a package, or are making one, and need help with that. For many upstreams, that's not the first thing they need: they might only have just heard of Debian, and making a package is much further down the road. Some possible questions: * We heard about Debian, and are wondering if it would be a good idea to have our software included. * People tell us Debian does not want our software, because it is hard to maintain. What's up with that? With whom should we talk about these issues? * There's an old version of our software in Debian, and we are tired of supporting it. What should we do to get it removed? * We'd like our software included in Debian. We don't know anything about packaging. Where can we learn more about this? * The Debian developer who maintained packages of our software in Debian has disappeared. Do you know how to contact them? Or can you help us find someone else? These are the kinds of questions that upstreams who are not already closely involved with Debian have. The point of the upstream front desk is not to replace existing communication channels, but to make sure there's a single easy way for upstreams to get in touch with Debian. The upstream front desk can then direct them to the relevant people, or the appropriate documentation. My interest in this stems from being retired from Debian for about a year and spending some time upstream. I experienced a little bit how hard it can be to approach a large project like Debian, even when Debian has extensive documentation on various web sites and wikis, plus lots of mailing lists, IRC channels, web forums, and other places for discussions. Or perhaps that's part of the difficulty: there's so much available that it's hard to get started. I don't know if having an upstream front desk will solve this, but I expect it will be helpful. If not, we can decide it's a failed experiment and end it. Here's what I'm hoping will happen: * We get more motivated, committed upstreams involved with Debian. * More upstreams understand how to make software that is easy to integrate into a Linux distribution. For the latter, the wiki page is an excellent resource, and the more ways we have of getting upstream developers to read it, the better. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1282424023.12989.353.ca...@havelock
Re: DEP-5: Structure for multiple copyright statements (was: DEP-5: general file syntax)
On su, 2010-08-22 at 08:00 +1000, Ben Finney wrote: Could we take advantage of the natural “©” marker to indicate each copyright statement? That's an interesting idea, but would people in general find it easy or difficult to write that character? (I'd have to copy-paste it, for instance, since my keymap does not seem to have a binding for it.) The word Copyright or the ASCII-art (C) might be substituted. Copyright: © 1995, 1997, 1998, 1999, 2002, 2003, 2004, 2006, 2009 Beatrice Bar beatr...@example.org © 2008, 2010 Barry Baz ba...@example.com What do others think? If I was writing a parser, I'd rather have the simplicity of long lines, but then I'm lazy. If I was writing DEP-5 files, I am not sure what I would prefer, but I know I would hate filling out the copyright fields in any case, since it's boring, repetitive work. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1282433814.12989.361.ca...@havelock
Re: DEP-5: Structure for multiple copyright statements
On la, 2010-08-21 at 16:41 -0700, Russ Allbery wrote: Ideally, I'd like to just copy and paste upstream's copyright statements into debian/copyright and maybe do some compaction, which leads me to prefer a free-form field. Do we think that people are going to want to parse and extract individual copyright holders for some reason? If so, we would need to standardize the format quite a bit, and I'm not sure it's worth it. If it was easy, I might be interested in analyzing the years indicated for copyrights, so I could write a little tool to notify me when things fall out of copyright. Oh, wait, I was living in a fantasy world for a while, one in which copyrights actually expire. Now that I'm awake, I'm happy to keep it free-form, at least for now. If it turns out to be useful later, we can specify a more strict format. (I will now go live in another fantasy world, one in which there is a markup language for copyright statements and licenses which upstreams regularly use.) -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1282434506.12989.367.ca...@havelock
Re: Upstream guide and front desk
On pe, 2010-08-20 at 14:55 +0200, Stefano Zacchiroli wrote: Now, I've no idea if the above would be appropriate for the upstream front desk or not. I leave it up to you to decide whether it's worth trying or not. I think a debian-upstre...@lists.debian.org mailing list, open to everyone and archived publically, would be best. An alias upstre...@debian.org could point to it, but I have no opinion on that. Anyone opposed to the mailing list? Shall I go and request one? No matter the technical solution, once it is done, we absolutely need to send out a Debian News item / press release about that. It is our best chance to increase awareness of the initiative within upstreams. Absolutely. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1282334011.12989.263.ca...@havelock
Re: [DEP5] [patch] Renaming the ‘Maintainer’ field ‘Contact’
On to, 2010-08-19 at 06:56 +0200, gregor herrmann wrote: A structured field makes it easier to parse; but as I said earlier, if we decide to keep (and at some point use) them we still can do so, if additional fields are allowed. There was a little bit of discussion on #debian-perl about this. Summary, if I understood correctly: pkg-perl would like to use Upstream-Name to more reliably connect a CPAN module and its Debian package (Homepage does not always point at the CPAN page), and Upstream-Contact to more easily connect a Debian package of a CPAN module with its author. I can imagine Python modules, and other such sets of modules, might want to do the same thing. These sets of modules have naming schemes, but they are not always 100% accurate. Now, it is certainly true that these are convenience fields, not strictly required by Policy or ftpmaster, but nevertheless interesting to a bunch of people. Thus it makes sense to me to standardize the name rather than everyone invent their own. The compromise between strict minimalism and overall convenience, if you will. I therefore intend to keep the fields in the spec, unless there's a wave of opposition. I hope that this is acceptable. (The volume of DEP-5 discussion dropped to low enough that it's getting hard to measure consensus. :) -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1282256623.12989.256.ca...@havelock
Re: [DEP5] [patch] Renaming the ‘Maintainer’ field ‘Contact’
On to, 2010-08-19 at 10:31 +0900, Charles Plessy wrote: my presonal point of view about fields in this DEP is that they should be required only if they are strictly necessary, and mentionned as optional only if there is a reasonable plan to parse and exploit the data. I am not aware of a requirement from the Policy or Joerg's message on debian-devel-announce in March 2006 for listing the package name in debian/copyright. Similarly, although it is required to list all authors of a packaged work, there is no requirement to list the upstream maintainer. Therefore, I think that the fields should be optional if they are not removed. I don't think they're required by Policy or the ftpmasters. At least the pkg-perl team is using Maintainer/Upstream-Contact. I don't think they use Name/Upstream-Name. It's reasonable to expect the package description to mention the upstream name if it differs from the Debian package name, and that would make Upstream-Name somewhat unnecessary. If pkg-perl, and perhaps others, are going to be using a field to keep track of the upstream contact information anyway, it makes sense to have a standard way of doing that. So I'd like to keep Upstream-Contact. Anyone else have an opinion on this? That is, should we drop Upstream-Name or not? Anyone opposed to keeping Upstream-Contact? (The fields will, obviously, be optional, if we keep them in the spec.) -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1282188247.12989.242.ca...@havelock
Re: [DEP5] [patch] Renaming the ‘Maintainer’ field ‘Contact’
On su, 2010-08-15 at 06:25 +1200, Lars Wirzenius wrote: So we have at least three suggestions on the table now: 1. Rename Maintainer: to Contact: 2. Rename Maintainer: to Upstream-Contact: and Name: to Upstream-Name: 3. Drop both Maintainer: and Name: completely, even as optional fields All three seem to have reasonable justifications. I'd like to see if we have a rough consensus favoring one of them. Can we see a show of hands, please? (If we don't, I'll have choose myself, and then it'll be 3.) It's my assessment that the rough consensus is in favor of either 2 or 3, with 3 getting more explicit votes, but 2 not getting any resistance, and having the justification that it's useful to a number of people. Thus, I will modify the spec to implement option 2. If there are objections to this, I'll be happy to revert the change until they're discussed. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1282075868.12989.122.ca...@havelock
DEP-5: general file syntax
There would seem to be at least a rough consensus that DEP-5 should follow Policy 5.1 on control file syntax. The open question how to specify that: it is my understanding that most people favor just referring to the relevant Policy section and not duplicate things in DEP-5, but since that is also my strong preference, I want to be careful. Here's my current suggestion: * We refer to Policy 5.1 by section number, section title, and URL. I don't think the policy version is necessary: if they make incompatible changes, then all Debian control files will potentially break, and DEP-5 copyright files are no exception. Including the 5.1 section verbatim in DEP-5, on the other hand, results in duplication, which is likely to result in divergence between the policy and DEP-5. * We add to DEP-5 details of how to handle values of multiline fields. We can discuss exact wording of that later (see below), if we can get consensus on the overall topic of file syntax. * Once DEP-5 is accepted, we move it into the debian-policy package; it will then be maintained via the normal policy amendment process on the debian-policy mailing list. If section 5.1 changes (including just number), the DEP-5 spec shall be changed at the same time. * We specify the debian/control Format: field to include an identifier that is not dependent on the DEP-5 URL. Currently, the spec includes a URL to the specific version of itself; this is obviously problematic. I suggest we change it by having two words in the Format: value: an unversioned URL to the spec (currently to the DEP site, but later to the debian-policy site), and a date. Comments on the above? The rest of this e-mail proposes a specific way of handling multiline values. - - - On to fields with multiline values. Well, every field can have multi-line values, but the generic rules suffice for most of them. There are three important details here: for specific fields, are newlines significant, can word-wrapping happen, and how empty lines are handled. For License, the text in the field (except the first line) should probably not be word-wrapped, newlines are significant, and definitely empty lines need to be handled in some way. The reason word-wrapping shouldn't happen is that in many cases upstream licenses use ad hoc plain text formatting conventions, such as bulleted lists, and any word wrapping will mess that up. There is already rough consensus on how to handle empty line markup (read: same as Description in debian/control). For Disclaimer, and Comment if we add that, it might be helpful to have empty lines, but word-wrapping is definitely needed. Newlines are not significant. For simplicity, I will introduce a new term, desc-escape. This refers to the escaping of content similar to the way Description does it in debian/control: each line is prefixed with a space, except empty lines are replaced with a space and period. The Policy's specification is not usable for this, I think, because it goes much further than what DEP-5 needs. Note that I've dropped the possibility of prefixing escaped lines with a TAB character. It is a needless difference from Description, and would complicate parsers. So there are three cases: * License: newlines are significant, no word-wrapping, desc-escape is used. * Disclaimer (and Comment in the future): newlines are not significant, word-wrapping is OK, desc-escape is used. * Everything else: newlines are not significant, word-wrapping is OK, desc-escape is not used. Normal RFC822-style handling of line continuations applies. In other words, for Disclaimer, a formatter would un-escape (remove leading space, replace lines with just period with empty ones), then split the resulting text into paragraphs at empty lines, and format those paragraphs in whatever manner it sees fit. I echo Charles's suggestion that we specify the way escaping is done in the section that describes the overall syntax, and then specify for each field if they use desc-escape or not, whether newlines are significant or not, whether the content can be word-wrapped or not. Comments on this part? I haven't got specific wording changes to suggest yet, I want to know if this approach is acceptable first, before we spend time on wording details. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1282080573.12989.179.ca...@havelock
Re: [OT] Re: [DEP5] [patch] Renaming the ‘Maintainer’ field ‘Contact’
On ma, 2010-08-16 at 16:19 +1200, Lars Wirzenius wrote: * a 24-hour moratorium on posting about DEP-5 at all That went well. Thank you everyone for giving space to breathe. * after that is over, not discussing every possible topic at once, just a couple at a time I've commented on two topics (general file syntax, in a new thread, and globbing syntax in the existing one). I would find it practical if we could stick to those for now, unless there is something urgent. This way, I think we can more easily keep track of what's going on, and this will help build consensus much faster. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1282081184.12989.188.ca...@havelock
Re: DEP-5: general file syntax
On ti, 2010-08-17 at 18:24 -0700, Russ Allbery wrote: Those exchanges aren't the actual license or copyright information, which can still be stated in a structured form. They're usually just defenses of why thet claimed license information is what it is (when it may, for example, contradict or supplement information included in the source files). Hmm. If the e-mails (or whatever) modify or clarify the license, should not the e-mails be considered part of the license information? License: other This software is released under the GPLv2 blahblah. . From: Upstream Author aut...@upstream.example.com Message-Id: loof.li...@upstream.example.com Date: Mon, Apr 01 2010 04:01:00 +0401 Subject: License clarification . When I say GPL I actually mean LGPL, sorry about that. If the e-mail is just a clarification to the license and does not modify it, then I guess License is not the right place. Rather than munge it into Comment, I guess we need a new field. However, how often do these things happen? If it is very rarely, we could just live with appending them to License. Having part of the file be non-machine-readable might be an option, but I have the feeling that for large debian/copyright files, it'd be easier to have these e-mails near the paragraphs that concern them, otherwise it'll get too difficult to keep track of things. So a structured approach would be my preference here. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1282108302.12989.199.ca...@havelock
Re: Upstream guide and front desk
On su, 2010-08-15 at 13:55 +0800, Paul Wise wrote: That sounds like a good idea. As long as I would not be alone, I would be willing to join such a list and answer questions from our upstreams. That's two of us. Anyone else who'd like to help? Two is enough to kick this off, though. I'll ask the DPL to take the next step. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1281888502.5840.116.ca...@havelock
Re: [DEP-5] [patch] Syntax of the files.
On la, 2010-08-14 at 21:39 -0700, Russ Allbery wrote: This raises something else I was thinking about. I believe that technical DEPs, if adopted, should move into the debian-policy package for further maintenance. I agree with this, with both my DEP-5 and DEP-0 hats on. (It's cold in Wellington, so two hats is appropriate.) 2) The Policy does not describe the DEP syntax for escaping empty lines. Policy §5.1 does not describe the mechanism of using a space plus a dot to escape empty lines in field values, but we can not refer simply to §5.6.13 (Description) because the DEP-5 License field is verbatim, whereas the debian/control Description filed requires an additional space to signal verbatim sections. Yes, this should be described in DEP-5. I propose, in the description of the License field: * Remaining lines: Each non-empty line of the license text should be prefixed by a single space or TAB character. Empty lines should be replaced with a line consisting of a space or TAB followed by a period. (Empty lines lines contain nothing, or only whitespace characters.) If a debian/copyright file is formatted for display, the license text is not expected to be word-wrapped, but displayed as if it were program code, so that license text that uses one of the many conventions for plain text formatting will display OK. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1281892127.5840.187.ca...@havelock
Re: DEP-5: additional requirements to use with upstream
On su, 2010-08-15 at 01:32 -0700, Steve Langasek wrote: That seems sensible to me. I think it will require some significant restructuring of the text, to declare the License and Copyright fields in advance of references to them in the discussion of the header stanza, so maybe we should postpone the implementation of this change until we've cleared a few of the other issues? I'm fine with postponing the implementation. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1281892395.5840.198.ca...@havelock
Re: [DEP-5] [re-patch] Syntax of the files.
On su, 2010-08-15 at 16:01 +0900, Charles Plessy wrote: I attached three consecutive patches, that I think reflect our current discussion. - The first one is just a re-iteration of Lars' patch, in which I added the title of §5.1, and the version of the current Policy. Your patch also refers to a specific Policy Manual version, which I think is inappropriate (read: results in unnecessary work). If the Policy Manual changes here, the DEP-5 specification needs to change at the same time. Russ's suggestion of maintaining the approved DEP-5 spec in the Policy Manual source tree, using the same change process, solves that problem. (Your patch also claims to add a URL, which my patch already did.) - The second replaces stanza by paragraph. For these kinds of search+replace things, it's easier for me to just say to do that than to provide a patch I need to proofread. I've done the replacement and pushed the change. - The third explains how empty lines are escaped in field values. You say: In field values, lines containing a single space followed by a single full stop character are replaced by an empty line. The first space or tabulation is ignored. Why would a TAB+period not be acceptable for escaping an empty line? -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1281892510.5840.200.ca...@havelock
Re: [OT] Re: [DEP5] [patch] Renaming the ‘Maintainer’ field ‘Contact’
On ma, 2010-08-16 at 12:34 +0900, Charles Plessy wrote: Give me a break, please. Let's give everyone a break. DEP-5 has a long, complicated history, and various people's feelings or egos have been bruised over time. It would be good to avoid doing any more of that. The current hectic pace isn't helping. So, in all seriousness, I propose: * a 24-hour moratorium on posting about DEP-5 at all * after that is over, not discussing every possible topic at once, just a couple at a time Now, I have no authority or power to enforce either of the above. And that's not the point. This is an attempt to force people to do anything. This is an appeal to sensible adults to take a step back, to take a deep breath, and to calm down. I could do with some of that myself. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1281932372.12989.58.ca...@havelock
Re: DEP-5: clarify batching of copyrights, licenses in a single stanza
On la, 2010-08-14 at 10:04 -0700, Russ Allbery wrote: Steve Langasek vor...@debian.org writes: ... How about this (written without looking at the detailed wording of the document, so may need some massaging to fit into the flow): FWIW, I like Steve's patch and Russ's addition to it. Anyone object to them? -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1281809365.5840.51.ca...@havelock
Re: [DEP5] [patch] Renaming the ‘Maintainer’ field ‘Contact’
On la, 2010-08-14 at 11:18 -0400, gregor herrmann wrote: I remember CPAN maintainers (sic!) being interested in the status of their modules in Debian. Without a Maintainer (or whatever) field in d/copyright (or somewhere else but I don't know a better place) we are not able to provide a mapping for that. Would the Homepage: field that points at the module's CPAN page be good enough? On the other hand, the field currently known as Maintainer: is already optional, so it's OK to leave it out, and when it's useful to, say, pkg-perl, it can be added. Russ, since you objected to it, what do you think? About renaming it: I feel it would be better to be explicit that it's an upstream thing. Thus, Upstream-Maintainer or Upstream-Contact, and perhaps also renaming Name: to Upstream-Name: at the same time. What do others think? -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1281809881.5840.58.ca...@havelock
Re: [DEP5] [patch] Renaming the ‘Maintainer’ field ‘Contact’
On la, 2010-08-14 at 11:54 -0400, Joey Hess wrote: Similarly, the Name field is not data that policy requires be in debian/copyright. On my latest read of DEP5, I thought this was completly redundant with the already redundant source package name in the changelog, control file, etc. There's a number of cases where the Debian source package name differs from the name upstream uses. For example, Iceweasel. On the other hand, is it useful to track that? Perhaps not. So we have at least three suggestions on the table now: 1. Rename Maintainer: to Contact: 2. Rename Maintainer: to Upstream-Contact: and Name: to Upstream-Name: 3. Drop both Maintainer: and Name: completely, even as optional fields All three seem to have reasonable justifications. I'd like to see if we have a rough consensus favoring one of them. Can we see a show of hands, please? (If we don't, I'll have choose myself, and then it'll be 3.) -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1281810359.5840.65.ca...@havelock
Re: [DEP-5] [patch] Syntax of the files.
On la, 2010-08-14 at 10:16 -0700, Russ Allbery wrote: Proliferation of file formats is a bug, not a feature, when you're trying to make things readable by software. Indeed. I believe most of these issues are already addressed by referring to the syntax description in Policy with the exception of: Right. It is my understanding that the rough consensus is in favor of using the same syntax as for Debian control files in general (with Charles perhaps the only dissenting voice), so I propose the following attached patch to replace the Compatibility and Human-Readability section with a new short section referencing policy 5.1. (The existing section is giving requirements for the syntax of the file, such as human-readability, which was appropriate at the beginning of the development of the spec, but I think we don't need that in the spec anymore.) Does anyone oppose this? === modified file 'dep5.mdwn' --- dep5.mdwn 2010-08-13 05:09:06 + +++ dep5.mdwn 2010-08-14 18:39:15 + @@ -54,17 +54,12 @@ they have a problem with, even if the licenses are DFSG-free. For example, the Affero GPL. -# Compatibility and Human-Readability -The file must be encoded as UTF-8 and strictly formatted as a superset -of RFC2822 including significant newlines. Free-form text is not -allowed. - -The `debian/copyright` file must be machine-interpretable, yet -human-readable, while communicating all mandated upstream information, -copyright notices and licensing details. - -For the sake of human-readability this proposal avoids any complex field -names or syntax rules. +# File syntax + +The syntax of the file is the same as for other Debian control files, +as specified in section 5.1 of the Debian Policy Manual. +See http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-controlsyntax +for details. # Implementation ## Sections
Re: VCS issues ( Re: [DEP-5] [patch] Renaming the Format-Specification field to ‘Format’. )
On la, 2010-08-14 at 19:56 +0200, Tollef Fog Heen wrote: ]] Lars Wirzenius | On la, 2010-08-14 at 14:15 +0900, Charles Plessy wrote: | Where is this bzr repository | | http://bzr.debian.org/dep/dep5/trunk/ | | I don't know bzr.debian.org provides a web interface. I will, however, | make the latest revision be automatically published so everyone can view | it without having to check out via bzr. It does, look at http://bzr.debian.org/loggerhead/dep/dep5/trunk/files Cool! Then I don't think I'll spend effort on setting up a bzr hook to automatically publish the file, even if loggerhead only gives access to the raw markdown text. Markdown is supposedly easy to read (like plain text). When we push changes from bzr to svn, for the official DEP website, the HTML version will get generated anyway, and that's the version people who implement DEP-5 should be looking at. The bzr version is just a glorified shared editing system. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1281811850.5840.83.ca...@havelock
Re: [DEP-5] [patch] License table: more links and licenses.
On la, 2010-08-14 at 16:58 +0900, Charles Plessy wrote: After looking at http://spdx.org/licenses/, I realise that the very existence of a license list in DEP-5 is in question (not in this thread). However, since I had a version of the DEP with a more comprehensive use of web links for licenses, I propose the attached patch anyway. Actually, I am starting to think that maintaining a long list of license shortnames in DEP-5, many of which refer to rarely used licenses, is perhaps too much effort. Since the list really should be shared with other projects (SPDX and Fedora especially), it would perhaps make most sense to refer to it instead of incorporating it in the spec. I would, however, keep a short list of shortnames for the versioned licenses in /usr/share/common-licenses (excluding BSD, plain GFDL, plain GPL, plain LGPL, plain Artistic): Apache-2.0, GFDL-1.2, GFDL-1.3, GPL-1, GPL-2, GPL-3, LGPL-2, LGPL-2.1, LGPL-3. What do others think? -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1281813409.5840.96.ca...@havelock
Re: [DEP-5] [patch] Syntax of the files.
On la, 2010-08-14 at 15:05 -0400, Joey Hess wrote: Lars Wirzenius wrote: -The `debian/copyright` file must be machine-interpretable, yet -human-readable, while communicating all mandated upstream information, -copyright notices and licensing details. The rest is good, but I like that paragraph. I've resurrected that paragraph. New patch attached. === modified file 'dep5.mdwn' --- dep5.mdwn 2010-08-13 05:09:06 + +++ dep5.mdwn 2010-08-14 19:42:38 + @@ -54,17 +54,16 @@ they have a problem with, even if the licenses are DFSG-free. For example, the Affero GPL. -# Compatibility and Human-Readability -The file must be encoded as UTF-8 and strictly formatted as a superset -of RFC2822 including significant newlines. Free-form text is not -allowed. +# File syntax The `debian/copyright` file must be machine-interpretable, yet human-readable, while communicating all mandated upstream information, copyright notices and licensing details. -For the sake of human-readability this proposal avoids any complex field -names or syntax rules. +The syntax of the file is the same as for other Debian control files, +as specified in section 5.1 of the Debian Policy Manual. +See http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-controlsyntax +for details. # Implementation ## Sections
Re: DEP-5 meta: New co-driver; current issues
On pe, 2010-08-13 at 08:00 +, Sune Vuorela wrote: On 2010-08-12, Lars Wirzenius l...@liw.fi wrote: * Various things are easier if debian/copyright can be parsed and interpreted by software, rather than being free-form text. For example, answering questions like what stuff is GPLv2 only, and therefore incompatible with GPLv3?. This is quite useless as long as we are making copyright files for sourcefiles. I believe debian/copyright is supposed to cover both source and binary packages, so I think your premise is invalid. However, let's assume it is valid. Even so, I don't think it is useless to have debian/copyright machine parseable, even if it does not solve all problems. Having a partial solution is already better than nothing, since it will make it easier to find the cases where manual inspection will be needed. For example, in the example you gave, it is helpful to get a list of the packages where there might be a problem, and exclude the majority of packages where there is obviously no problem with license compatibility. Without automation, manual inspection is going to be necessary for all packages, and that's a lot of work. Now, obviously there are already tools that use pattern matching and other heuristics to figure out the licenses for each package. The point of DEP-5 is to reduce the guessing, and make it easier to automate things. It will not be a complete solution, but if it gets adopted, it will help. I like the comparison with debhelper. It also does not solve the entire problem (though dh comes close), and we can't ever make it mandatory, but even so, it makes everyone's life quite a lot easier. For some people, for whatever reason, it doesn't help enough to warrant the effort to convert to it, so they don't, and that's fine, too. And I think that's just about enough from me on the topic of justifying the point of making debian/copyright machine readable. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1281721952.2017.31.ca...@havelock
Re: DEP-5 meta: New co-driver; current issues
On pe, 2010-08-13 at 08:04 +, Sune Vuorela wrote: On 2010-08-13, Lars Wirzenius l...@liw.fi wrote: On pe, 2010-08-13 at 09:08 +1000, Craig Small wrote: I tried to use it once on one program and just ditched it. It only made it more difficult for me and for anyone who read it. That would indicate there is a bug in the DEP-5 spec. It is, in my very non-humble opinion, not acceptable for DEP-5 to make it harder to maintain debian/copyright in DEP-5 format than as a free-form one, except for minimal markup. It seems that the process so far has created I like to offer people to try to do a DEP-5 based copyright file for e.g. src:kdebase-workspace, even the overhead from 'minimal markup' is actually ending up as quite a big thing. Here's a quick-and-dirty conversion to DEP-5, which took about an hour to do, using regular expression searchreplace, the vi . command, plus manual editing: http://files.liw.fi/dep5-long-example.txt Some statistics: originaldep5 bytes 64053 38853 words 70983363 lines 17961100 The DEP-5 version is shorter, without (I think) sacrificing precision. It saves space by avoiding repeating boilerplate text such as The full text of the GNU General Public License version 2 is available on Debian systems in /usr/share/common-licenses/GPL-2. every time the license is used for a module. Now, I admit that my DEP-5 version is a) quite dirtily created b) in need of review and c) certainly incorrect. I did not, for example, bother to fix up all lists of file specification to handle exceptions. I claim, however, that DEP-5 is not going to make it larger. The original file already had some markup, using some markup language (not sure which, but similar in spirit to resturctured text and markdown, and it might have been one of them). Also, there was something that looked like markup for lists of files. You might be able to write a script to convert from your markup to the DEP-5 one. Whether you want to do that or not is of course up to you. Whether you want to use DEP-5 or not is up to you. I don't care. To me, this idea that DEP-5 has a massive over head now a equestrian zombie. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1281726663.2017.44.ca...@havelock
Re: DEP-5 meta: New co-driver; current issues
On pe, 2010-08-13 at 11:39 -0400, Joey Hess wrote: However, there is a big, big problem with DEP-5, and it is named /usr/share/doc/chromium-browser/copyright. It is 1.3 mb in size (out of a 25 mb package), and completely unreadable and unusable. It appears to be machine generated, and is full of redundancies and useless information. (So I am very skeptical of claims that we should machine-generate copyright files.) It could probably be replaced by a hand-written file of about 20k. IMHO, we should not allow such unnecessarily complicated copyright files in Debian. Ouch. Yes, the chromium-browser debian/copyright file does not seem sane to me. If an automatic tool is used to generate it, it should take care to minimize the size, right now there is a lot of duplication there, and that's silly. I doubt that is fixable in DEP-5, though. If they didn't use a machine-parseable format, the could just generate a similar free-form file, with the same amount of repetition. (The root problem seems to me to be that chromium-browser is an aggregation of a large amount of code from other projects. I don't think that's a sustainable way of developing software in the long run. It might work for one project at a time, but it harms the ecosystem.) -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1281727355.2017.47.ca...@havelock
Re: DEP-5: additional requirements to use with upstream
On pe, 2010-08-13 at 09:49 -0700, Russ Allbery wrote: My opinion on this is that using # as a comment marker is already a diversion from RFC 5322 and I was surprised that dpkg had support for it. If we want this to be used outside of Debian, sticking strictly to the syntax for RFC 5322 headers seems like a good idea to me since we're staying with a format with known parsers. I think I agree with Russ on this one. I'll propose a Comment: field later. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1281727489.2017.48.ca...@havelock
Re: DEP-5 meta: New co-driver; current issues
On pe, 2010-08-13 at 17:11 -0700, Russ Allbery wrote: I would read approval in this context as approval by all the people who are interested in using something like DEP-5. In other words, consensus that, should one want to do this sort of thing, this is the way in which we're going to do it, with explicit acknowledgement that some people aren't interested in doing this sort of thing at all. That is exactly right. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1281758868.5840.13.ca...@havelock
Re: DEP-5 meta: New co-driver; current issues
One more piece of meta: We the drivers are now using the wiki page[0] to track outstanding issues, in the interest of transparency. We'll be updating it as we go along. Further, in order to avoid having everything discussed at the same time, I think it would be good to discuss one or two things at a time. I'll raise the next topic whenever discussion dies on the previous one. Or someone else will, that's obviously fine. [0] http://wiki.debian.org/Proposals/CopyrightFormat -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1281759357.5840.17.ca...@havelock
Re: [DEP-5] [patch] Renaming the Format-Specification field to ‘Format’.
On la, 2010-08-14 at 11:29 +0900, Charles Plessy wrote: Renaming the Format-Specification field: This seems like a completely noncontroversial suggestion. The only reason to avoid doing it is to avoid having to fix all the existing files, but since they need to be fixed for other things anyway, and this is easily scriptable, I think we can ignore that. Does anyone oppose this change? If not, I'll apply the patch on about Monday (NZ time), and if someone opposes it later, I can always revert it. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1281759570.5840.21.ca...@havelock
Re: [DEP5] [patch] Renaming the ‘Maintainer’ field ‘Contact’
On pe, 2010-08-13 at 20:43 -0700, Russ Allbery wrote: Am I missing some other Debian document somewhere that says we should be providing upstream contact information in debian/copyright? I realize that lots of people do this, but it's not at all clear to me that it makes sense to put that information in debian/copyright as opposed to one of the many other places we could store such information. For example, upstream usually provides much more complete contact information including preferred methods of contact and related information, in a README file that we would normally install with the package documentation. There's also the Homapage: field in the package description. I don't have a use case for a Maintainer/Contact field in debian/copyright. Can anyone bring one up? -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1281759939.5840.23.ca...@havelock
Re: VCS issues ( Re: [DEP-5] [patch] Renaming the Format-Specification field to ‘Format’. )
On la, 2010-08-14 at 14:15 +0900, Charles Plessy wrote: Where is this bzr repository http://bzr.debian.org/dep/dep5/trunk/ I don't know bzr.debian.org provides a web interface. I will, however, make the latest revision be automatically published so everyone can view it without having to check out via bzr. I also disagree with Steve on this: it doesn't matter all that much whether you base a patch on the version in svn, or wherever, as long as it's clear what is being changed. You don't even need to provide a patch, you can just provide a new wording, and I'll edit things into the file manually. Now, can we please stop displaying our bruised egos and get on with fixing the spec? -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1281763378.5840.31.ca...@havelock
DEP-5 meta: New co-driver; current issues
The effort to get a machine-readable format for debian/copyright has been going on for some years now. I think it is time to get it done. To help with this, I am joining Steve Langasek as a driver for DEP-5[0]. [0] http://dep.debian.net/deps/dep5/ The story so far, in a very rough summary: * Various things are easier if debian/copyright can be parsed and interpreted by software, rather than being free-form text. For example, answering questions like what stuff is GPLv2 only, and therefore incompatible with GPLv3?. * Started on the wiki in 2007, just over three years ago. Now using the DEP process. Many people have participated in the discussions. * Quite a number of packages already use some variant of the DEP-5 format. There's no goal to make using it mandatory, however. (Compare with debhelper: almost all packages use it, but it's entirely optional.) * Most of the spec seems reasonably stable, some details need to be fixed. It would be good to have DEP-5 done quite early in the squeeze+1 development cycle to give as much time as possible for adoption. The current outstanding issues I am aware of: * a Comment field would be good * license shortnames/keywords: the set of keywords probably needs work, and hopefully can be compatible with what other projects use; the current thread on the meaning of public domain is part of this * file globbing syntax * clarify the text so it's clear DEP-5 won't require more precision than is currently needed If there's more issues, please raise them. I will be be starting separate threads on the above topics later (in other words, please don't discuss these topics in this thread, only the meta stuff). My role as driver is not to make decisions, but to guide the discussions, and update the DEP-5 document based on the consensus of the discussions. In a bikeshedding situation, however, I will use editorial control and pick a winner in order to guide the discussion to more productive topics. (In other words, the more you bikeshed, to more power I get.) I am aiming for the following workflow: * We discuss, on debian-project, whatever issues need discussing. * I and Steve update the DEP-5 draft, and post a diff. * If there is something else to discuss on that topic, we do that, otherwise we move on to the next one. It was just suggested we move the DEP-5 discussions off debian-project. I think that would be a mistake. This is something that affects the project as a whole, and should therefore be easy for the whole project to follow, now and in the future via the list archives. If we keep DEP-5 in the subject, it'll be easy to filter away for those uninterested. If we build DEP-5 outside the normal project structures, we'll just have to re-discuss it when it's time to approve it, so it's better to have the discussion just once. Uh, this e-mail became longer than intended. Thanks for reading this far. Let's get this thing done and out and finished and over with. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1281617130.2264.35.ca...@havelock
Re: Moving discussions about DEP-5 details to another list. (Was Re: DEP-5 and public domain)
On to, 2010-08-12 at 13:58 +0900, Charles Plessy wrote: Stefano, as admin of the DEP Alioth project (I think that the others retired), would you agree to create a dedicated mailing list for DEP-5? I volunteer for the mailman administration, and for taking the responsibility that no major changes are discussed there instead of on debian-project. Alternatively, we could use an existing list, for instance debian-legal. I'm un-retiring, and also becoming a co-driver for DEP-5, in order to get it finished reasonably soon. See the meta e-mail I just sent out to -project. For what it's worth, I am opposed to a DEP-5 specific mailing list. See my other e-mail for reasons. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1281617469.2264.38.ca...@havelock
Re: DEP-5 meta: New co-driver; current issues
On to, 2010-08-12 at 14:59 +0200, Bernd Zeimetz wrote: On 08/12/2010 02:45 PM, Lars Wirzenius wrote: It would be good to have DEP-5 done quite early in the squeeze+1 development cycle to give as much time as possible for adoption. A few comments: - Personally I find the format unnecessarily complicated and much more annoying to use than writing a normal debian/copyright file, especially for complicated cases. You're not required to use it. If you want to improve the format, please make concrete proposals, or at least explain why it is complicated and annoying. (If you've already done so, a URL will be sufficient. I do not, unfortunately, have the time to re-read three years worth of old discussions about this.) - Migrating all packages to the new format is an insane task which would take a *long* time and a lot of work. There is no goal to migrate all packages. That's a strawman. - Instead of writing such files (and keeping them updated), we should put more energy into doing this task automatically. It is obviously true that it would be good to make all of this reliably automated. However, even when that is done, it's useful to have things in one place in a Debian package, i.e. debian/copyright, and it'll still be useful for that place to be machine parseable. More importantly, making debian/copyright be machine parseable provides some immediate benefits, without having to wait for a solution to the big, difficult problem. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1281619632.2264.65.ca...@havelock
Re: DEP-5 meta: New co-driver; current issues
On pe, 2010-08-13 at 09:08 +1000, Craig Small wrote: I tried to use it once on one program and just ditched it. It only made it more difficult for me and for anyone who read it. That would indicate there is a bug in the DEP-5 spec. It is, in my very non-humble opinion, not acceptable for DEP-5 to make it harder to maintain debian/copyright in DEP-5 format than as a free-form one, except for minimal markup. It seems that the process so far has created an impression that a DEP-5 file should be incredibly specific and detailed, and we'll have to fix that. You really need to stop and think what is this for? What information is important to have and what can be found in the source files later if someone really cares. The answer (obviously to me, but not so obviously to others) is that it should have the same information as a free-form copyright file, at the same precision as the free-form file would have, while allowing more precision for those who want provide it. My suggestions: * Split out the authors and the copyright dates into one chunk. The fact that fileA is copyright 2005 Joe and fileB is copyright 2006 Fred and then fileC is copyright 2006 both of this is completely irrelevant for most people, just that Joe and Fred have copyright of some parts of the package is enough. Files: * Copyright: 2005-2006, Joe 2006, Fred But I'll bring this up later in a separate thread, since there is a detail that may need discussing. * Make it possible to say this package is licensed under foo except fileA which is licensed under bar Files: * License: foo Files: fileA License: bar More importantly, making debian/copyright be machine parseable provides some immediate benefits, without having to wait for a solution to the big, difficult problem. What are these benefits? From me initial mail in this thread: 'For example, answering questions like what stuff is GPLv2 only, and therefore incompatible with GPLv3?.' (With 'stuff' being 'package', and not 'file'.) -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1281658184.2264.115.ca...@havelock
Re: DEP-5 meta: New co-driver; current issues
On to, 2010-08-12 at 10:32 -0700, Don Armstrong wrote: It would also be nice to take a hard look at the SPDX format,[1] adopt any good ideas from it, and try to make sure that the resultant DEP-5 can be translated into SPDX, and vice versa. [There's no reason for us to do all of the hard work of copyright and license auditing and verification when we can colaborate with the work of others.] I've had a look at one version of the SPDX draft, and I agree that it's good to ensure convertability. SPDX has different goals from debian/copyright, and seems to be even more verbose than DEP-5 (they have no globbing, each file is listed separately), so using the exact same format probably isn't sensible. But convertability from one format to the other would be nice, and should not be excessively hard, either. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1281672312.2264.134.ca...@havelock
Re: DEP-5: additional requirements to use with upstream
On to, 2010-08-12 at 17:14 -0700, Russ Allbery wrote: As mentioned in the other thread, one goal for DEP-5 for me is to make the format sufficiently rich to allow me to use it for the upstream LICENSE file. Towards that end, I have three changes I'd like to have. Thanks, that's an interesting use case for the file format, and I'm glad you brought it up. * An additional section with the same syntax as the Files section but with no Files field that would be used for documenting the copyright of the distribution as a whole. (In US law, this is called a compilation copyright.) This is not the same thing as a Files: * section, which would specify a default copyright and license for any individual file that doesn't have other information. In some edge cases, the compilation copyright and license can be different than the copyright and license of any individual file in the distribution. I am uncomfortable signalling compilation copyright just with the absence of a Files: field. It seems to error prone to me. It would be better to be explicit, I think. What would be a good way of being explicit in this case? * A comment field in the header section into which I can put statements like: All individual files with no other license statement are released under this license. Some files have additional copyright dates from earlier releases or may be owned by other copyright holders as noted in those files. Some files are individually released under different licenses, all of which are compatible with the above general package license. Would a generic multi-line Comment: field be sufficient? * An origin field in the files section where I can note the origin of that set of files. For example, my packages contain some files copied from GNU Libtool, and I currently say that in the LICENSE file. I don't want to lose that information. This use case could be served by just allowing a comment field in the files section, I suppose, and that may be a better approach since it's more general. Perhaps it'd be sufficient to stick to a generic Comment: field for now, until there's some experience to see what other new fields are useful in the real world. This would be my personal preference. If others think an Origin: field would be good to have, I'll add it, my job as DEP driver is to record consensus. Can you suggest a wording? What do others think? Anyone for or against and Origin: field? -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1281676915.2264.154.ca...@havelock
Re: DEP-5 meta: New co-driver; current issues
On pe, 2010-08-13 at 09:57 +0900, Charles Plessy wrote: The “paragraph” format that is popular in Debian control files does not allow the use of free comments. [- - -] ... I propose to use a simpler format, that is trivial to parse: Having debian/copyright use the same file format as debian/control would seem to me to be a plus. People are already used to writing in that format, and there are parser implementations for the format, so it's a very convenient one to use. The format even allows using '#' for comments. Therefore it is my personal opinion that we should stick to this. However, as DEP-5 driver, I will record any consensus that emerges. If there is wide support for Charles's new format, I'll modify DEP-5 to use that. So if you support it, please speak up now. (Until and unless a consensus in favor of the new syntax is clear, I will assume the consensus is for the syntax in the current revision of the specification.) On the other hand, it was noted by Don yesterday and by Steve in December that other projects, in particular Fedora, also use short names. I think that it important that we converge on a common set. I proposed in December to contact Fedora, but did not get positive answers on debian-project. I volunteer again to contact Fedora and the Linux Foundation as a DEP driver, to propose them to use a common set. The SPDX people are collaboration with other projects, including Fedora, on this right now. Steve and I discussed it and he'll join the SPDX mailing list to represent us, and will relay any concerns and updates. (I don't know if the SPDX list is public. I hope it is. If someone can find out and post a URL to their list archive, it would be a good thing.) Personal opinion: mostly the license shortnames should just require agreeing what they are for each of the most common licenses, and it doesn't really matter what the exact string for each one is. I'm OK with anything that is unambiguous. I would like to see us avoid painting this bikeshed as much as possible. Unbranding -- To my knowledge, you were the first to suggest this. I can't remember what this is about. Can you refresh our memories? I am running out of time, but that is already a couple of things to discuss. I have not commented on most of your topics, because I have no opinion on most of them. If others comment and there's a consensus for the changes you propose, I'll edit the spec accordingly. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1281678216.2264.170.ca...@havelock
Re: DEP-5: additional requirements to use with upstream
On to, 2010-08-12 at 22:28 -0700, Russ Allbery wrote: Lars Wirzenius l...@liw.fi writes: On to, 2010-08-12 at 17:14 -0700, Russ Allbery wrote: * An additional section with the same syntax as the Files section but with no Files field that would be used for documenting the copyright of the distribution as a whole. (In US law, this is called a compilation copyright.) This is not the same thing as a Files: * section, which would specify a default copyright and license for any individual file that doesn't have other information. In some edge cases, the compilation copyright and license can be different than the copyright and license of any individual file in the distribution. I am uncomfortable signalling compilation copyright just with the absence of a Files: field. It seems to error prone to me. It would be better to be explicit, I think. What would be a good way of being explicit in this case? Maybe allow Copyright and License fields in the header? This would also has the advantage of being the way, in DEP-5, to do what several people are asking for and just state the license for the whole package without enumerating files, equivalent to what they're doing without DEP-5 now. (This differs from a Files: * block in that the latter makes specific claims about individual files, whereas the general copyright and license statement does not and has the same granularity as most upstream license declarations.) This sounds good to me. Does anyone object? -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1281678321.2264.171.ca...@havelock
Upstream guide and front desk
I gave a talk[0] at Debconf10 about my experiences switching from being a Debian developer to being an upstream developer. As part of that talk I suggested two things: * a guide or checklist for upstreams so they know how do things so their software is easier for distributions to package * a contact point within Debian for upstreams to use For the first thing, I have started a wiki page[1], and seeded it with points from my talk. I hereby declare it to be the ultimate truth, absolutely correct, and forever final. (That should be challenge enough to get people to update it with new ideas, and fixes.) For the second thing, I propose an upstream front desk of some sort. Stefano, in his role as the DPL, agreed that it would be good. The UFD would be the point of first contact for new upstreams, and would guide them to the right people in Debian to help them with the packaging of the upstream software. They could also help upstreams later, if there are problems in their relationship with Debian, e.g., the volunteer Debian package maintainer goes missing. I am not sure what the best way to implement the UFD would be. Perhaps a mailing list (debian-upstream?) with a few volunteers would be a good start? If this gets created, I'll join. Anyone else like to help with that? [0] http://liw.fi/swimming-upstream/ [1] http://wiki.debian.org/UpstreamGuide -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1281489432.2264.10.ca...@havelock
Re: Upstream guide and front desk
On ke, 2010-08-11 at 10:29 +0900, Charles Plessy wrote: Do you know about http://wiki.debian.org/GettingPackaged ? It looks like there are many overlaps between this page and the one you created… Thanks, Charles, for pointing that out. That page does, indeed, have much overlap with my UpstreamGuide page. They should be merged -- and since UpstreamGuide is newer, it should be merged into GettingPackaged. Maintenance and improvement of the page, and making sure all relevant parties know about it, would be another task of the upstream front desk, I think. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1281490749.2264.13.ca...@havelock
Bits from the DEP0 drivers
[ I am not subscribed to debian-project currently; please Cc any responses. ] A few things related to Debian Enhancement Proposals (DEPs) and DEP0. For background, see http://dep.debian.net/ . - - - First, commit access to the SVN repository: In June, the issue rose whether non-DDs should be given commit access to the repository: http://lists.debian.org/debian-project/2009/06/msg00017.html . The consensus of the DEP0 drivers, who maintain the repository, was against this, and there was no real opposition to it either, so the current state of affairs continues. - - - Second, we made some modifications to the DEP0 text at Debconf and immediately after. A summary of the changes: * Added wording to stress that the drivers merely act as secretaries, and have no additional power to decide things during discussions. * Added wording to indicate that dep.debian.net is the central archival location; working drafts can be stored elsewhere. * Added a diagram to explain the state diagram. * The DROPPED state was renamed to REJECTED. * REJECTED proposals cannot be resurrected (but may be re-numbered if someone wants to try again). * Some refactoring of the text for better clarity. * Fixes to typos and such. - - - Third, we have changed the state to CANDIDATE, from DRAFT. We feel that there is a consensus for this, since no outside changes have been suggested to the DEP. If anyone objects, now is the time. - - - Fourth, we've added some introductory text and the new state diagram to the front page of dep.debian.net, in the hope that people will find that easier than reading all of DEP0. - - - Fifth, two of the three DEP0 drivers are currently more or less on an extended vacation. This should not cause any urgent problems, but if someone wants to join the DEP0 driver team to help maintain the DEP process itself, please e-mail Zack at z...@debian.org. - - - Thanks, and happy hacking! Stefano Zacchiroli Lars Wirzenius -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian redesign
ke, 2009-07-29 kello 12:46 -0300, Margarita Manterola kirjoitti: Discussing about this on irc, some people seemed to agree with my view that the female images are too sexual, and that the image of the notebook on the pillow is disturbing. I agree with Marga in that I don't think these images are appropriate for marketing Debian. This doesn't detract at all their artistic and other qualities, but I don't think we as a project should use sexuality, eroticism, or nude figures, to market ourselves. It is not just ethically wrong and degrading, it also tells people we have no substance. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [OT] aggressiveness on our mailing lists.
la, 2009-07-25 kello 23:12 +1000, Ben Finney kirjoitti: If what remains is an attack upon an *idea*, so be it; ideas don't have feelings and are not automatically deserving of respect or politeness. “This is a silly idea” attacks no-one and is impolite to no-one. Let those who support the idea come to its defense as they choose; if an idea has no able defenders, let it fall under the attack to clear the way for better ideas. While that is true in principle, it is also true that people often have an emotional attachment to ideas they propose, and may be unable to fully prevent the feeling that an attack on their idea is also partially an attack on themselves. (It doesn't help that sometimes that is true.) It is thus often more constructive to express criticism in a gentle and genteel fashion. This does not require approval of a bad idea. For example, in the specific case under discussion, the criticism might have been expressed something like this instead: I think this is a bad idea. It creates extra work for developers just to retain their membership in the project. The proposal so far has been based on activities that developers do anyway, and that is good. Inventing new things DDs must do to keep their membership is a bad idea. I also think unsolicited pings to active developers are a bad idea and should be avoided. Now, if there is active work going on that does not reflect itself in uploads, then I can see using a signed/encrypted email to a role address every couple of years or so could be a workaround to the automatic MIA process. That should be the exception, though. Almost everyone should be covered by the usual process. I believe that if such wording could have avoided the current sub-thread, so we could have concentrated on the actual issues. (My apologies to Manoj if I have misinterpreted his feelings and thoughts. My apologies to everyone for continuing the meta-discussion.) -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [OT] aggressiveness on our mailing lists.
la, 2009-07-25 kello 09:16 -0500, Manoj Srivastava kirjoitti: You are making the assumption that the authors reaction to Bad is less negative than the reaction to Silly. While this is subjective, I do not think it is without contention: My hasty re-wording has now given the wrong impression, sorry. My main point is that it is often possible to express misgivings about things other people propose without exiting the realm of the polite. I hope I can claim that is true even though I failed to completely do so myself. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
DEP: commit rights to dep repositories on alioth
Currently, the dep project on alioth (which can be used to host DEP texts on $VCS) allows commits by any DD, but not guest accounts. The question has arisen whether to allow commits by guests. Doing so would allow basically anyone to start a new DEP, or, more importantly, to change existing ones. We, the original proposers for the DEP process, feel opening the repository to everyone would carry too much risk. Instead we propose that either each driver team include at least one DD, who does the actual commits to the dep repository as the draft gets changed, or the DEP draft gets maintained elsewhere and merged by a DEP0 driver (or any volunteer DD) into the dep repository when it has been accepted, or at major milestones during its development. In the latter case, the dep repository would contain a pointer to the actual location of the DEP-in-development until it has been finalized. Rationale: DEP texts are not the places were to frantically _develop_ franticly the actual DEP, but just places where to record the state of the art of the proposal, as it has been agreed upon by other means (e.g., consensus on mailing list, as we usually do). In the same vein, the drivers should usually act just as secretaries for a given proposal and it doesn't look like that wide commit access rights are needed to that end. What do other people in the project think? Lars Wirzenius, Stefano Zacchiroli, Adeodato Simó -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian MiniConf @ LCA2010 in Wellington — help needed
ke, 2009-06-17 kello 17:24 +1000, Pascal Hakim kirjoitti: It's really easy to find people to talk at mini-conf once LCA has started or is about to start - there's just that many DDs who attend. It's much harder to get someone to commit to something early enough that you can get it included within the programs. For what it's worth, I intend to be in New Zealand at that time anyway, and intend to come to LCA. I would be happy to commit to giving a talk at the miniconf, on piuparts. Unfortunately, my life until then is going to be too hectic to participate in actually arranging things. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Re-thinking Debian membership
I promised to get back to re-thinking Debian membership processes. After everything that's happened, I think it would be best to postpone discussions about this until after Lenny is released. I am planning to start or join that discussion after the release. (And, yes, I hope to do a DEP on it, but that's pretty much irrelevant to everyone else.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Logo stoled
su, 2008-10-26 kello 09:24 +0200, Kadath kirjoitti: Hello. Checkout this website, it looks like they steal Debian logotype. http://www.pure-organic-baby-food.co.uk/ It's not an exact copy of the Debian logo, and Debian does not have a monopoly on swirls. Thus, I think it is not a problem. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re-thinking Debian membership
pe, 2008-10-24 kello 23:47 -0700, Steve Langasek kirjoitti: I think it would be more sensible to kick out the people who don't do anything for the project *except* vote. That is certainly a good point. The reason I propose counting voting only is that that's the only action all DD would have in common that would be unambiguous. Not every DD would be uploading packages, and other stuff like mailing list activity, commits to version control systems, editing the wiki, BTS activity, etc, is a long list of possibilities we would have to draw lines around in some way. For example, is it enough to be occasionally active on -user? Is once a year enough? Should the quality of one's packages be a concern? How do we coalesce [EMAIL PROTECTED] and [EMAIL PROTECTED] and other e-mail addresses for the same person, especially if not all of them are in the key in Debian's keyring? I like simplicity, so I chose the simple option. There does not seem to be a consensus that this is a good option, so I'll amend my proposal accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re-thinking Debian membership
la, 2008-10-25 kello 09:59 +0200, Stefano Zacchiroli kirjoitti: A scenario I want to avoid for example is that newcomers can alter the keyring adding tens of friends. Such a possibility would imply that if Debian as a project fails *once* in checking IDs and motivations for *a single* newcomer, than that newcomer can screw us badly adding a whole lot of people. I presume the range of nasty scenarios starting from this one is quite big. I would like to stress that my proposal says that any changes should be easy to undo. This is especially true for anything that may result in nasty scenarios. I haven't thought about the mechanics of this yet in any particular detail, but there are so many ways in which keyring maintenance could be arranged to achieve the goal of my proposal that I'm not worried it can't be implemented. That doesn't mean I'm adamant on having the keyring be NMUable by any DD. As an aside, I realize that all of my proposal is written very quickly, and is very short. The length is mostly a good thing. I wanted to get the idea out soon, and to see how the discussion goes. Since the core parts of my proposal seem to be received mostly in a positive manner, I think it's time to start working on a more detailed proposal, and I hope to use the DEP process for it, and gather input from all relevant or interested parties in the project. I probably won't have time to work on it for a few days, and it might be good to postpone most of it until after lenny is released anyway. However, since Joerg started the discussion, I think it was appropriate to throw the idea out now. More generally, the solution to concentration of powers is making sure that the same people do not play too many roles in core teams (ideally, max 1), because that gets rid of communications to self, which are always hidden to the rest of the project. I think that would be a good idea. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re-thinking Debian membership
I do not like the way Joerg wants to change the way people become and are members of the Debian project. It's not all bad, but on the whole it makes some of the worst parts of Debian become worse. It concentrates power into fewer hands, removes some of the benefits of the Debian Maintainer process, adds more hoops to jump through, and makes the whole question of what it means to be a member of Debian massively complicated. I think we should go in the opposite direction: massively simplify the whole membership thing. I believe, very strongly, that the important distinction between someone who is a member of Debian and someone who is not is that the member may vote in Debian matters. I further believe that we should give voting rights to people once we as a project have gained trust in them: that they agree with the goals of the project, as encoded in the Social Contract, that they have a commitment to work on those goals, and that they have personal integrity to be worth our trust. I do not believe the current New Maintainer process measures those things in a practical way. I wish to suggest a replacement process. Further, I do believe that being able to upload packages is another very fundamental right for a member in the Debian project: our operating system is divided into packages, and development of the system is what we do. I would like to keep things simple and give upload rights to everyone. The most important reason for this is that we don't want as a member anyone who can't be trusted with the permission to upload. I am not worried about mistakes: mistakes can be fixed, and they help people learn. On the other hand, a graphical artist might, for example, upload a wallpaper package. I do not believe detailed division of rights will result in anything but control freaks being a hindrance to development. I believe that Debian has an unfortunate history and tendency to let people take on more and more work, and get more and more power, resulting in situations where particular people have way too much influence. I don't think these people are evil, and I doubt their primary motivation is to gather power. I do, however, believe that it harms the project to have a few very powerful people in control of some central points in the project. I also know it can be very hard to give up power once you have it. Thus, I believe we're better off setting things up so that no-one has special powers, unless they really, really need them. The other end of the membership process is screwed up too. We should not have to actively seek out members who are Missing In Action. Staying a member in Debian should be an active process: if you don't do anything, you should be automatically retired. Proposal * People should be allowed to join Debian when there is reasonably wide-spread consensus that they agree with the project's goals, are committed to working on those goals, and are trustworthy. The best way to determine this is to have some number of people endorse a candidate. However, there should not be too much opposition to a candidate, either. Concrete proposal: max(Q, 20) endorsements, two existing members together can veto. The veto can be done anonymously via the Debian Account Manager to avoid peer pressure to not veto. The DAM only counts the endorsements and vetos, and does not make judgement calls. All endorsements and vetos must happen within 30 days. * Membership in the project gives both voting and upload rights. * Membership ends 24 months after they're given, or after the latest participation in a vote arranged by the project's Secretary. Members may retire themselves earlier, of course. * Members may be expelled via the normal General Resolution process, with a simple majority. Ftpmasters may temporarily limit upload rights in an emergency. * Membership is controlled via GnuPG keyrings, primarily maintained by the Debian Account Manager. The keyrings shall be maintained in a way that allows any member to change them, and that is fully transparent to the members in general, and that further makes it easy to undo mistakes. * Upload sponsorships and the limited upload rights via the Debian Maintainer status are unaffected by this proposal. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re-thinking Debian membership
pe, 2008-10-24 kello 11:42 +0200, Michael Hanke kirjoitti: What does this mean? It automatically ends after a vote or two years? Or is it rather (semi)automatically extended by continued contributions of a yet to be defined type (e.g. package uploads, bug reports/fixes)? You become a member, and you'll be a member for two years. If you vote, the timer resets and you will again be a member for two years. Vote again, and the timer resets again. Etc. The resetting is automatic, as is the retiring. No other contributions are counted, just voting (an abstain vote is fine), because otherwise we get into a mess of defining what kind of contribution counts and what does not. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re-thinking Debian membership
pe, 2008-10-24 kello 12:18 +0200, Peter Palfrader kirjoitti: On Fri, 24 Oct 2008, Lars Wirzenius wrote: * The keyrings shall be maintained in a way that allows any member to change them, Since you refused to explain on IRC, please explain the rationale and use-cases here. To be accurate, I asked you to move the discussion to -project. Here, it is visible to everyone, and doesn't require the kind of real-time attention that IRC does. The rationale is simple: to avoid concentration of power into the hands of the few, and keep it in the hands of everyone. Since I believe the decision on someone's membership should be collectively in the hands of all the members, I don't think the task of editing a keyring should be restricted to one or a couple of people. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re-thinking Debian membership
pe, 2008-10-24 kello 13:36 +0200, martin f krafft kirjoitti: also sprach Lars Wirzenius [EMAIL PROTECTED] [2008.10.24.1044 +0200]: * Membership is controlled via GnuPG keyrings, primarily maintained by the Debian Account Manager. The keyrings shall be maintained in a way that allows any member to change them, and that is fully transparent to the members in general, and that further makes it easy to undo mistakes. There is no way I will ever agree to something like this unless we get rid of all the inactive or careless members we already have. I'm all for moving inactive people to retirement status. The fact that we don't do that well is one of the things I believe my proposal will mostly fix. Having hundreds of (potentially unsafe) keys with upload rights to our archive, which isn't actually needed in many many cases is one thing; allowing all these keys to approve or delete members is another. Since any changes need to be easy to undo, and we need safeguards around such decisions anyway, I don't see a problem. For example, there could be a time-delay between adding a new member and the time when they can actually log in. Ditto for removing a member. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
pe, 2008-10-24 kello 16:56 +0200, Wouter Verhelst kirjoitti: If you insist. Note that I'll vote against it -- I've never liked procedures whose sole purpose is to change procedures. For what it's worth, as one of the three people who suggested DEP in the first place, I would be unhappy to see it made mandatory, and would vote against a GR suggesting it. As far as I care, DEP should be a tool, for those who wish to use it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re-thinking Debian membership
pe, 2008-10-24 kello 22:51 -0500, Manoj Srivastava kirjoitti: * Members may be expelled via the normal General Resolution process, with a simple majority. Ftpmasters may temporarily limit upload rights in an emergency. So expulsion by DAM's is a power you are proposing to remove? Or is this in addition? I would make expulsion happen only via a GR. I can live with DAM keeping that power. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re-thinking Debian membership
pe, 2008-10-24 kello 22:56 -0500, Manoj Srivastava kirjoitti: The keyring does not have to be exposed directly. It could work via a delaying queue or stanging area. Changes commited to be applied to the keyring could be made publicly available for peer-review. This would make it possible that any change could be veto'ed by any other project member during the delay period. Who takes the action to expose the modified keyring? I would make it automated, via e-mails, RSS feeds, or some other suitable method. If the keyring it maintained in a version control system, for example, all changes require a commit, and all commits can generate an e-mail to a suitable list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian and non-free
ti, 2008-09-16 kello 18:14 +0200, Marco d'Itri kirjoitti: I am happy to not have as users and especially as fellow developers the kind of people who use gNewSense. I believe that gNewSense is a great idea, since it tends to keep far from Debian the worst nutcases. And the Diplomat of the month award goes to Mr. d'Itri! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DEP1: Non Maintainer Uploads (final call for review)
pe, 2008-09-05 kello 10:00 +0200, Stefano Zacchiroli kirjoitti: On Thu, Aug 21, 2008 at 10:20:44AM +0200, Lucas Nussbaum wrote: on http://dep.debian.net, using the same license as DEP0, but dep.debian.net is down currently, so I can't check what the license is :) dep.debian.net was just an alias for http://dep.alioth.debian.org. I don't know what happened to the DNS entry in Debian's LDAP, but you can refer directly to the above URL. A license is not yet listed in DEP0, but was agreed upon. I'm quite sure Lars (Cc-ed) remember it. Lars: can you comment on that? It is in bzr. I don't know how to update the web page, actually. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DEP1: Non Maintainer Uploads (final call for review)
ke, 2008-08-20 kello 09:38 +0200, Raphael Hertzog kirjoitti: The maintainer is still king and if he decides that the NMU was not a good idea, he would have no other choice than skipping a revision in the changelog. That would be confusing. It would, however, make things a bit more explicit than what happens now. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DEP licenses
pe, 2008-05-30 kello 11:42 +0200, Simon Josefsson kirjoitti: I believe it would lead to less problems to require that all DEPs are licensed under a liberal and widely compatible license, such as the Expat, X11 or the modified BSD license. I agree that that would be more convenient. I don't know if there's consensus that we should do it. However, if no-one objects within a couple of weeks, I'll add a suggestion to use the Expat license in a couple of weeks or so. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)
pe, 2008-05-30 kello 04:34 -0700, Richard Hecker kirjoitti: I just do not see the value when some Johnny-come-lately decides that all the decisions need to be reworked. I'd like to add my voice to the choir of people who think the length of participation in Debian development should not matter. I find that Lucas has given good justifications to support his view. The fact that he's only been around Debian for several years now does not mean that his point of view can be dismissed by someone just because they've been around a few years more. Seniority is not irrelevant, but it has no power against valid arguments. Complete agreement by everyone is not necessary for consensus. As far as I can see, there have been few people talking against the changes DEP1 proposes. While the process is still going on, and there's certainly still plenty of opportunity to come up with reasons why DEP1 should not go forward, for now it seems there is a rough consensus that it should. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)
pe, 2008-05-30 kello 22:01 +0900, Charles Plessy kirjoitti: Le Fri, May 30, 2008 at 02:50:28PM +0200, Raphael Hertzog a écrit : Please come back in 2008! ;-) You speak as an elder that doesn't want to move forward But no, you prefer to not explain your problem... Please stop this pissing contest... I have read better emails from you, Raphaël. The difference between using the BTS and asking the maintainer is that dropping a patch in the BTS is not asking the maintainer if the NMU is welcome. Patch to the BTS plus a DELAYED/n upload (with a sufficiently large n) is, to me, a way of asking the maintainer. It is, perhaps, less smoothly diplomatic than e-mailing privately, but I don't really see that it is rude. One e-mail response from the maintainer should be enough for the DELAYED upload to be deleted (by the would-be NMUer, of course). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)
pe, 2008-05-30 kello 09:49 -0700, Steve Langasek kirjoitti: Sending a patch to the BTS is not sufficient - the mail to the BTS must also clearly state the intent to NMU, so the maintainer knows the mail must be handled with a high priority. I agree with that, of course. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
