On Mon, Feb 07, 2022 at 09:28:16PM -0500, Theodore Ts'o wrote: > > > On Mon, Feb 07, 2022 at 12:06:24AM -0700, Sean Whitton wrote: > > >> When we treat any of the above just like other RC bugs, we are accepting > > >> a lower likelihood that the bugs will be found, and also that they will > > >> be fixed.... > > > Another part of this discussion which shouldn't be lost is the > > > probabiltiy that these bugs will even *exist* (since if they don't > > > exist, they can't be found :-P) in the case where there is a NEW > > > binary package caused by a shared library version bump (and so we have > > > libflakey12 added and libflakey11 dropped as binary packages) and a > > > NEW source package. > > Which category of bugs do you mean? I distinguished three. > The argument why a package which has an upstream-induced shared > library version bump, has to go through the entire NEW gauntlent, is > because it is Good Thing that to check to see if it has any copyright > or licensing issue. But if you have a different package which doesn't > have upstream-induced shared library bump, it doesn't go throguh the > same kind of copyright and license hazing. And I believe this isn't > fair. > Either we should force every single package to go through a manual > copyright/licensing recheck, because Debian Cares(tm) about copyright, > or "copyright/licensing concerns are an existential threat to the > project" (I disagree with both arguments), or a package such as > libflakey which is going through constant shared library version bumps > should not go through the NEW gauntlet just because it has new binary > packages (libflakey11, libflakey12, libflakey13, etc.) at every single > upstream release. Thanks, this is the exact point I wanted to make here (although rather than saying it isn't "fair", I would say it isn't sensible as a criterion for review). The fact that the FTP team applies license/copyright review as part of their review of source packages has grounding in a number of goals of Debian as a project. The existence of a binary NEW queue is also sensible, as the FTP team have to manage the namespace of the packages in the archive. But the application of license/copyright review by the FTP team for existing source packages as part of binary NEW processing /and at no other time/ is arbitrary. It is, at best, a historical accident that has taken on the authority of precedent. Guarding against debian/copyright drift is a useful goal. But it is harmful to the velocity of the project to either block or reject new binary packages in the archive because of this linkage to license review. Actively-developed library packages with ABI changes are not fundamentally more likely to have license drift than any other package in the archive, so focusing FTP team time on reviewing the licenses of these packages in particular is a misapplication of resources. The responses I've seen from the FTP team to this can, I believe, be roughly paraphrased as "we would like all debian/copyright in the archive to be clean, but we don't have capacity to do that, so we're doing this instead". I assert that it is much, much worse to continue doing this than to do *no* license/copyright review as part of binary NEW. It does not achieve the goal of having clean debian/copyright across the archive; it slows down the binary NEW queue due to (self-imposed) workload of the FTP team; and it deters developers interested in this problem space from innovating better (and more systematic) solutions outside the small FTP team. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: PGP signature