* Russ Allbery <rra@debian.org> [2022-02-04 11:48]:
No, that's fine, that's not a strawman argument. That is, in fact, my argument: I think it should be okay to put crap packages in the unstable archive and fix them later, and I would rather put more effort into the "noticing" part than in the pre-review part. [...] Now, all of that being said, I also want to say that I'm sketching out one end of the argument because I think that end has been underrepresented. I don't think this is an all-or-nothing binary choice. We could, for example, focus our review on only packages that are viewed as riskier (only packages with maintainer scripts or that start daemons, for instance, or stop doing NEW review for packages uploaded under the auspices of well-established Debian teams, or stop doing NEW review for shared libraries whose source packages are already in Debian), all ofwhich would be improvements from my perspective.
In my opinion, this is a very important train of thought, because not all crap is created equal. While some things can be fixed easily with a new upload, others have permanent repercussions, for example: - It is impossible to undo an epoch bump, or more generally, revert to an earlier version number. - The package namespace can be polluted, or existing names can be hijacked, potentially rendering names unusuable for future uploads (particularly if the hijacking version number is sufficiently large and/or epoch'd). I'm not implying any ill-will, merely observing that people make mistakes, and some mistakes are more costly to rectify than others. The FTP team review should focus on these types of mistakes, and not only with new packages: any "suspicious" upload should be rerouted to a POLICY queue for additional verification. There is some prior art with the auto-REJECT on Lintian errors, which could be extended to a three-way decision (ACCEPT, POLICY REVIEW, REJECT). For instance, we could flag epoch bumps or major version numbers which skip ahead significantly (think 020220101 instead of 0.20220101). We can certainly continue to flag new binaries and potential copyright violations (e.g., packages with incompatible licenses or files with "(?i)(?:do|must) not distribute" in their headers), or anything else we consider important. The automated checks need not be perfect as long as we avoid false negatives on the critical issues. And I imagine it will also speed up the review considerably if the FTP team already knows what problems (not) to look for. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────────────────────────────────────────────────────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄⠀⠀⠀⠀ ╰────────────────────────────────────────────────────╯
Attachment:
signature.asc
Description: PGP signature