On Friday, February 4, 2022 12:39:09 PM EST Russ Allbery wrote: > The Wanderer <wanderer@fastmail.fm> writes: > > What I read Scott as having been suggesting, by contrast, is that people > > instead do copyright review for packages already in Debian, which may > > well have had changes that did not have to pass through NEW and that > > might not have been able to pass the NEW copyright review. > > > > If a practice of doing that latter were established and sufficiently > > widespread, then it would not be as important to do the review for every > > package in NEW, and the FTP team might feel less of a need to insist > > that the review take place at that stage of things. > > Various people have different reactions to and opinions about the > necessity of this review, which I understand and which is great for > broadening the discussion. But I feel like we're starting to lose track > of my original point, namely that I don't see why we are prioritizing this > particular category of bugs over every other type of bug in Debian. The > justification has always been dire consequences if we don't stamp out all > of these bugs, but to be honest I think this is wildly unlikely. > > In other words, this thread is once again drifting into a discussion of > how to do copyright review *better*, when my original point is that we > should seriously consider not doing the current type of incredibly tedious > and nit-picky copyright review *at all*, and instead rely more on > upstream's assertions, automated tools, and being reactive in solving the > bugs that people actually care about (i.e., notice). > > In other words, what if, when upstream said "this whole package is covered > by the MIT license," we just defaulted to believing them? And if there's > some file buried in there that's actually covered by the GPL, we fixed > that when someone brought it to our attention, or when we were able to > detect it with automated tools, but we didn't ask people to spend hours > reviewing the license headers on every source file? What, concretely, > would go wrong? > > Scott correctly points out that there are a ton of copyright bugs in > Debian *anyway*, despite NEW review. He sees this as a reason for not > relaxing our review standards. I see it as the exact opposite: evidence > that our current review standards are not achieving the 100% correctness > we have claimed to be striving for, and the nearly complete lack of > practical consequences for that failure. It really seems to me like > evidence that this task is not as important as we think it is. A substantial fraction of packages uploaded to New are not deemed to be sufficiently policy compliant to enter the archive. I don't have numbers, but if it was more than a quarter of them, I wouldn't be surprised. It's true that the bulk of that is due to copyright/license issues, but it's not all of it. While most of the severe bugs we find are in this area, that's not all we look for. I disagree with the premise that all DDs can and do create packages of sufficient quality that no check point is needed to assess them before they enter the archive. My experience is that this is just not true. We review a lot of genuinely awful stuff that's uploaded even when it's known there will be a review in New. If we kept the New queue in place, but didn't review the correctness of d/ copyright, it would make it faster to review packages, but I don't think it makes sense to make that one aspect of policy that the FTP Team decides to ignore. I think most of your argument is with Policy 2.3. We don't search out the true source/licensing of files in the packages we review. There are cases where the upstream file indicates it was copies from elsewhere and the license/copyright attribution is ignored, but generally we assume that what is in the package is correct. Since we're doing strawman arguments in this thread: I disagree with the notion that it's not a problem to put crap packages in the archive and fix them later if anyone happens to notice. Scott K
Attachment:
signature.asc
Description: This is a digitally signed message part.