Hi, Stefano Zacchiroli wrote: > You mean something like: http://ftp-master.debian.org/REJECT-FAQ.html ? > But I see your point. Also note that that list is not IMO clear enough > to explain Steve's reject (i.e. it does not state «we will reject any > source package with at least one file not accounted for by > debian/changelog»). But still it is a good start. I guess that it should ^ copyright > just be better advertised (pointer from developers-reference?) and > clarified as soon as cases like this one arise. The reject FAQ has been featured on d-d-announce[1], is linked from the NEW queue page and, AFAIK, referred to in most if not all rejection mails from Joerg. It does have (under the innocently named item "License"): "We often find packages having a GPL COPYING file in the source, but if one goes and looks at every file there are a few here and there having different licenses in them, sometimes as bad as You aren't allowed to do anything with this file, and if you do we will send our lawyers to you."
"if one goes and looks at every file" seems to be indicative of the expectations in NEW review. But of course, you could always suggest patches. And really, we are discussing three questions here - Should the debian/copyright apply to source packages as well as binaries? And my (personal and de facto working) opinion is it should if only because I would expect documentation to be forgotten with the initial upload more often than intentionally not put in the binaries. Also, when we do require freeness of the source packages as well as the binaries, it seems not too unreasonable to require license information for all of it. In particular it is not a policy that was just made up for the sake of it, but something a quite natural evolution of requiring copyright information and freeness of "everything". Finally, it somewhat reduces the amount of time it takes to check stuff if one does not have to inspect which file is put in which binary package. - Should packages with neglected debian/copyright pass NEW if you managed to put the bad stuff in the archive without anyone noticing? Having filed a couple of serious bugs for similar cases, sure that works, too, but it is a lot more tedious: One has to check whether the bug is present in the unstable package (it could be introduced with the new one), take the version etc. For every single package, that is not a problem, but I did not yet process batches larger than some 10 packages yet, either. When doing a lot of NEW, that is fairly tedious - it involves a bunch of extra screens to look at in addition to the two or three already in use for doing NEW. Given that it does not save the maintainer a lot of work (reuploading after a reject vs. timely attending to the RC bug about the license), it seems to me that rejecting the package is not that bad a choice efficiency-wise. OTOH if people, to avoid the reject, could be bothered to look at their copyright file every couple of years when package names change, we would not have to have this discussion and actually get a less buggy archive.[2] - If it something passed NEW last time, should that necessarily happen the next time as well? An oversight does not invalidate the problem, does it? Kind regards T. 1. last time at http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html 2. Seriously, what do you answer NMs asking why there are so many substandard copyright files in Debian when doing QA work? That it used to be more difficult a few years ago? -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]