* Scott Kitterman <deb...@kitterman.com> [2022-04-29 23:32]:
I don't understand why this is any better than just rejecting the package? Once it's been determined that the upload won't be accepted, I don't see a benefit to having it remain in New.
I think this is a matter of perspective: for the FTP team, the upload is basically a stateless process; a package is either fit for inclusion in the archive or it is not. For the uploading DD, it is merely a particular (undesirable) state in the packaging process. The NEW queue is a mandatory review of their packaging effort, and the REJECT is feedback which they will (hopefully) address, and then try again. Maybe, in some circumstances, they will abandon the package, but I'd say that this not typical.
Converting the NEW review process into a bug-centric approach instead of a mail-centric approach reinforces the DD's point of view, focusing more on the package upload as a part of package maintainership. The question is: how will this affect the FTP team's point of view? If it will clutter the NEW queue with half-processed packages, I'd say it is a bad tradeoff, because it adds mental load to the FTP team. At a minimum, there needs to be appropriate tooling which allows to distinguish easily between new packages requiring FTP team review and packages waiting for fixes to be applied. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────────────────────────────────────────────────────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄⠀⠀⠀⠀ ╰────────────────────────────────────────────────────╯
signature.asc
Description: PGP signature
