Markus Koschany <a...@debian.org> writes: > I have a hard time to imagine what kind of breakage might occur with > those non-Lintian parsers.
It's pretty straightforward: currently, a License field must either contain an extended paragraph or references one elsewhere in the document. Therefore, whenever a parser sees a License field without an extended paragraph, it currently knows (and expects) there to be a stand-alone license paragraph later in the document. But with this change that paragraph wouldn't exist. > I personally dislike the trend in Debian to create more and more > complexity in our source packages. Well, I think avoiding changing the version of the standard and adding this special case (and special-casing a specific set of licenses) adds *more* complexity to the format than my proposal, as did the brackets. It requires encoding options and branches and multiple interpretations of the same field. Simplicity is exactly why I want to just change the version number, introduce a new field with a clear meaning and syntax, and have clean and simple semantics in the new version. > I find the Standards-Version field unnecessary, VCS fields should not be > part of a debian/control file, all DFSG licenses approved by our > ftp-team should be listed in /usr/share/common-licenses and maintainers > allowed to reference them, simple clarifications for copyright format > 1.0 elements should not require a separate document 1.1 and so on. That's an interesting assortment of things that seem very, very unlike each other to me. Including a few I agree with (such as VCS fields not being in the debian/control file; I'd love to find a good migration strategy to move such metadata about the package maintenance process, as opposed to a single instance of a source package, out of debian/control for a cleaner separation of concerns). Personally, I'd be happy to have all approved licenses listed in common-licenses (there are a few complexities to actually doing that, but it would be nice if we worked those out) since it would make my life a lot easier, but you'll have to take that one up with the embedded systems folks (and minimal container folks, for that matter), who have indicated they'd be quite *unhappy* about that. (I suspect the base-files maintainer wouldn't be thrilled either.) One of the jobs of being a Policy Editor is to try to keep in mind the widely varying uses to which Debian is put and to try to chart a course between those concerns. The common-licenses compromise is awkward and not particularly graceful, and it would be nice to have a better approach, but I don't think shipping several megabytes of text in base-files is the one that's going to make everyone happy. > I have noticed that you are always in the opposite camp and a proponent > for more complexity. I believe this kind of perfectionism makes it more > and more difficult to change even smaller details in Debian. This amuses me a lot, since part of what I've tried to do in Policy in the past year or two has been to argue against perfectionism and to push things forward despite some objections and desire to get all the details more correct, to the considerable annoyance of some folks. It is certainly true that Policy is probably too bureaucratic, and I'd like it to be more streamlined and faster as well. But formulating standards through consensus is hard, and every standards process ends up having this problem to some extent if it's successful. If you think this is bad, you should try the IETF or, heaven forbid, POSIX. :) Debian is really large, and there are a lot of edge cases, and standardization becomes the place where we find all those edge cases and talk about them and try to write them down. If anyone has figured out how to do that without being bureaucratic, I haven't heard about it. I think what you're seeing is a large and mature project with a stronger committment to quality and consistency than you find in most communities. (And, to be fair, quite a lot of momentum and adherence to "the way things have always been done," probably more than we should have.) That inherently comes with a certain lack of agility. I wish we could have both at the same time, but I think it might be a constraint of human nature. > For me #883950 and this proposal is a no-brainer and should have been > handled much more gracefully. Yup, that's a common theme -- just about everyone who comes to Policy for a specific proposal thinks their proposal is a no-brainer (but usually has some objections to some other proposal someone else had, like putting VCS fields into debian/control). > I'm not surprised that I can't convince you but for the sake of other > Policy bug reporters, I suggest that you make your decision making > process more transparent in the future. For instance I was asked by one > Policy editor to contact the ftp-team, which are the authoritative body > in Debian when it comes to licenses, I got the OK for my proposal but > now it is blocked by another Policy editor who subtly implies that the > resolution of this bug depends solely on him. It would have saved us > time and effort if we got that straight right from the start. I think you're confusing two very different things. You were asked to reach out to see if they felt the need to have an explicit pointer to the file in common-licenses in debian/copyright, which you did, and they don't, and that's great. That unblocks a big chunk of this. Thank you very much for doing that! We also need to check with them on whether the license grant needs to be copied into debian/copyright, since that would get rid of another chunk of work. (That's now a separate bug.) I only raised my concern about backward compatibility *after* you had checked with ftp-master, because that was the first time I'd had a chance to really think about that implication of the proposal in detail and realized it had that issue. So I obviously wouldn't have asked you to ask them about that, since it hadn't occurred to me. It's also not something we would ask ftp-master about in particular, since it's a format issue, which is outside the scope of stuff they care about. So I think you've gotten the timeline a bit confused here, and are (understandably) frustrated about a speed bump that didn't come up until late in a long discussion. I'd say that's my "fault" in the sense that I could have raised it earlier if I'd noticed it, but I'm not going to take any blame on it because Debian is a volunteer project and sometimes people just don't have time to think about things until they're farther along. It happens. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
