Re: Sprint on Seturday 12th July: Reforming ftpmaster team

[Nicolas Mora <babelouest@debian.org>]

Hello,

As a new ftp-master trainee, here is my feedback on the BoF and more 
generally my observations on the NEW packages process.

I apologize in advance if I say silly things because of my inexperience 
of the inner ftp-master team.

So far my review tasks was on packages in the NEW queue, but I used the 
Salsa repo as source, as I don't have access to the ftp-master 
infrastructure. It didn't bother me most of the time, as packages are 
usually in salsa. Some of them were not and at least one other didn't 
have the debian/ folder in salsa but they are the exception.

I liked it the way I did though, because I could organize myself with 
tools I already know like my beloved geany and a sort of todo list 
manager to log my progression and notes on the review.

Le 2025-07-13 à 08 h 16, Anton Gladky a écrit :
>   * *New Package Processing Delays:
>     *it was acknowledged that new packages often wait a long time
>     in the queue. This delay is a significant point of frustration for
>     Debian contributors.
In that case, having packages in NEW because of a soname change or when 
a new package is added from the same source can be frustrating 
sometimes. Although I learned to be patient about that.

We could split the NEW queue into two (or more?) branches: one for the 
new packages with an ITP that need to be fully reviewed, and need enough 
time to process, another one when a package is updated because of the 
soname change or when the package has an update, like the t64 or a 
change I recall in one of my package [1]. It could help the ftp-masters 
to organize their upcoming work.

On the other hand, sometimes, some packages get a huge change in the 
source code when bumping to a new version, but there is no change in the 
compiled package, so no reason to send it to NEW.
This can be error prone, because the maintainer may not know about the 
changes or could miss the implication.

On this last statement (if it's relevant), I don't have a solution, the 
maintainer is the first and most important part of the solution, but we 
could add a 'helpdesk' without having to push a package in NEW: "Please 
ftp-masters, can you review my package?"

>   * *Communication:
[...]
>   * *Proposed Solutions:*
>
>       o The main proposed solution is to move the new package processing
>         work to a separate host. This would allow more people to safely
>         participate in reviews without needing access to the critical
>         main archive server.
If we can afford it thanks to the legal changes or so, it would be 
awesome! It would also be better not to worry breaking the main servers.

More generally, having the NEW queue in a more open infrastructure 
wouldn't harm for sure, but we should need to change some parts of our 
processes then.

But I'm the new guy here, maybe there are some impacts or problems I 
don't even know about.

> *Existing Problems*
[...]
>   * The current technical architecture, which relies on a single host,
>     makes it difficult to onboard new team members and improve
>     processing times.
Also could it lead to security issues if you have too much critical but 
different things at the same place?

/Nicolas

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043108