Am 02.08.2018 um 12:43 schrieb Russ Allbery: > Markus Koschany <a...@debian.org> writes: > >> Please keep it simple. I disagree that we would need a version bump of >> copyright format 1.0 which had to be documented in every >> debian/copyright file again by changing the Format field. A simple >> amendment would also do the trick which could be referenced by the >> Policy and our copyright format 1.0 document. > > Well, I gave my reason why I think we need a version bump. Could you > explain why you think it's not necessary with a more specific discussion > that answers that analysis?
In short: The whole idea of creating a new document 1.1 or 2.0 is overkill in my opinion, at least for this change. It is completely reasonable to update or amend a "legal" text without having to call the whole thing constitution 2.0. You appear more concerned about one parser, Lintian, than about the human maintainers who have to update d/copyright again. You argue that the maintainers have to update d/copyright anyway, I say fixing the tool is far more efficient because it affects far less human beings. Lintian can be updated to recognize common licenses. It can be told that a common license wouldn't need a standalone paragraph with the license grant anymore, instead it could nag people to remove it if it existed. Nothing will break because no tool besides Lintian checks debian/copyright for copyright format 1.0 compatibility. You would be right to demand a version bump if we were talking about a _license_ change. You can't just retroactively change that. But we are talking about a non-legally binding document that simply explains how users should read our d/copyright file. Moreover we should, no we must, expect that users read this document because otherwise we could just drop the Format field with a link to the documentation. It is just inconceivable that people, who are really interested in the package's license terms, will not read it. I also recommend to avoid a discussion about new fields and considering the inclusion of SPDX identifiers to "solve" this issue. While I'm absolutely not against the latter, I believe it should be discussed in a separate bug report. This bug report should really only be about reducing license grant boilerplate and for that we don't need another field. >> Updating a single tool, a parser like Lintian, is far more efficient >> than updating ten thousands of source packages again. > > They don't have to update the version unless they want to use the new > feature, at which point they're being modified anyway. I would expect to > have 1.0-format files in the archive for years, and that's fine. That's > the reason why there's a version number. > > The first version bump is always the hardest, but if we're going to have a > version number at all, we should bump it when we make > backward-incompatible changes. The whole point to having a version number > is to change it when something changes that a consumer needs to be aware > of. As I previously tried to explain I don't feel that there is a compelling reason for such a new version number because there is no severe backwards-incompatible change. I can see where are you coming from but the "consumer" is a tool called Lintian, not really impossible to solve. >> Please also read what Joerg Jaspert has written in > >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883950#80 > >> again. Even the ftp-masters prefer a keep it simple solution and they >> support our proposal to reduce boilerplate. > > I don't think Joerg recognized the backwards-compatibility issue. Well, to me it looks like he didn't recognize it because there isn't any but let's just ask him again to be sure. (that's probably the discussion in #904729) Markus
signature.asc
Description: OpenPGP digital signature
