Sean Whitton <spwhit...@spwhitton.name> writes: >> My personal suggestion would be to work with one or two volunteers to write a >> somewhat-comprehensive how-to-ftpmaster-the-NEW-queue manual, so that the >> *next* time you have a bottleneck you can throw that document at the >> volunteer >> and say "here's ten example packages, find their problems if any, then come >> back". > > The docs are public: https://salsa.debian.org/ftp-team/manpages
Those are helpful even for me as uploading packages to NEW! I wish I
had read them before.
Is there any policy to forbid or accept uploading two packages A and B
at the same time to NEW where package A depends on package B?
I am guessing based on earlier e-mail interactions that this causes
problems for your review workflow, so I've stopped doing simultaneous
uploads and instead upload package B first and then wait for ACCEPT and
then upload package A etc.
That policy lead to a slow migration path, since for many Go packages
the dependency chain of NEW packages can be quite deep. If I recall
correctly, I had this dependency situation earlier:
sigstore
-> sigstore-go
-> cosign
-> gittuf
-> gitsign
It would be nice to clarify in those documents if indeed there is a
policy on this. It seems surprising to me, since it would make it
impossible to get a set of NEW packages which have cyclic dependencies
into Debian.
Of course, a more gray situation like "we don't want to forbid it but it
causes us more work so please don't do it" is perfectly fine too.
Writing that down helps people do the right thing. The question has
come up two times for me when sponsoring new Go package uploads.
/Simon
signature.asc
Description: PGP signature
