On May 1, 2022 4:44:21 PM UTC, "Timo Röhling" <roehl...@debian.org> wrote:
>* 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.
I don't think that answers my question at all.
Yes, someone could invest a bunch of time in updating DAK so that known
unacceptable packages wouldn't clutter the review que, but how would that be
better than what we have now?
What does it help to have it sitting there instead of rejected?
Scott K
