Hi, * Matthias Urlichs <matth...@urlichs.de> [2025-03-05 23:00]:
The NEW queue currently contains ~135 packages. The median wait time on the list(*) is three weeks, and the oldest packages have been, well, languishing, for nine months or so.I'm not an FTP Team member, but I happen to have analyzed exactly this question in detail [1]. The FTP team is very transparent in this regard and provides all processing logs, so any DD can verify this for themselves.(*) Yes I know that this may well be an inflated median: after all, the packages which ftpmaster *did* process lately are not on the list by definition. However, that's still 50 people who've been waiting for at least a month to get their package into Debian.
In summary, the median wait time in NEW is currently less than 48 hours, and in the last 10 years it was seldomly longer than a week. 90 percent of all packages going through NEW are processed within a few weeks. Only 2 percent of all packages going through NEW are held up for several months or longer.
A typical months sees about 400 packages going through NEW, and up to twice that many in the month or two directly after a release, when maintainers rush to catch up with upstream releases or introduce new stuff for the next release cycle.
That means that in an average month, more than 200 packages pass through NEW within two days, and only about 20 packages get stuck for more than three or four weeks.
So why do people feel NEW processing is generally slow? I have a few ideas:
1. People looking at the current state of the NEW queue easily fall prey to survivorship bias; they see mostly the problematic cases and almost none of the simple ones.
2. Source packages going through NEW merely because they introduce new binary packages are typically processed faster than completely new ones. Maintainers for C/C++ libraries, which need to go through NEW on a semi regular basis, tend to have a much smoother overall experience than, say, Python maintainers, who only interact with NEW when they introduce new packages.
3. Source packages have varying degrees of complexity for debian/copyright, which is not necessarily the maintainers fault (some upstreams seem to treat code with various licenses as some sort of Pokemon-style collection challenge), but the maintainer has to deal with it in a way that the FTP team can sign off on it. And that may take some time (on both ends).
4. There is a certain variability in processing times which naturally comes from the fact that everything we do is volunteer work, which is totally out of the maintainer's control. I've seen packages pass through NEW within hours, one time even in less than 60 minutes(!), and I've waited on a similar one for weeks.
The difficulty to know how long the trip through NEW will take has a significant psychological impact. Close to my home, there is a railway crossing on a relatively busy track. If the barriers come down, it can mean a wait time from a minute (a single train) up to 20(!) minutes (with several and/or long trains in close sucession). This does not happen very often, but you have no way of knowing in advance. Thus, people take significant detours to avoid that level crossing, as they'd rather add five minutes for certain to their trip than roll the dice for an unlucky quarter hour.
Cheers Timo [1] https://people.debian.org/~roehling/new_queue/ -- ⢀⣴⠾⠻⢶⣦⠀ ╭────────────────────────────────────────────────────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄⠀⠀⠀⠀ ╰────────────────────────────────────────────────────╯
signature.asc
Description: PGP signature
