Timo Röhling <roehl...@debian.org> writes: > 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).
I feel like it would also be a lot easier to get volunteers to look at packages that had already been flagged, rather than do green-field reviews of every package everyone uploads (most of which are entirely fine or have at most minor issues). It certainly feels like a more interesting problem to me! "Here are a few things that looked weird, please manually look at this package to see if they're a problem." Or even "this package has maintainer scripts that aren't just debhelper-generated boilerplate, please look at them and make sure they're not going to run rm -r / or something crazy." > 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. Exactly. We're not going to catch everything, to be sure, but we're not catching everything *now*, and improvements of automation scale in ways that trying to do more painstaking human review do not. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>