Skip to content

Rethink or clarify the objectives of NEW queue review

This is a reiteration of [1]. Related discussions include [2,3] and probably many more.

I believe that the way we currently think about the NEW queue review is flawed. While the goals of the review are laudable, and the work put in by the FTP masters in performing the review is impressive, there are paradoxes: A package that entered the archive 20 years ago and which has ever only produced a single binary, may have had only one review and trip through the NEW queue. The package may well have been completely rewritten or relicensed upstream several times, but that does not affect whether or not it needs another trip through the NEW queue. At the other extreme, a package that builds a library binary with frequent SOVERSION bumps may need to go through the NEW queue many times per year, even if upstream has barely changed and its license remains the same.

This (seemingly needless) delay propagates to other packages and developers, and is perhaps motivation-sapping for some (I for one find it hard to "save" one moment's motivation and free time for a few weeks/months until a package has cleared the queue.

The current setup is rather arbitrary, and slows down development (and, I suspect, makes attracting new contributors harder) for little real gain. Or, if we instead assume that the gain from the review in the latter case is real, then the problem becomes instead that this scrutiny is lacking for the former kind of package. At any rate, not a great situation.

As for solutions, I admittedly don't have any. Some ideas were floated in [3,4].

[1] https://lists.debian.org/debian-devel/2021/11/msg00237.html

[2] https://lists.debian.org/debian-devel/2020/02/msg00118.html

[3] https://lists.debian.org/debian-devel/2022/01/msg00226.html

[4] https://lists.debian.org/debian-devel/2022/01/msg00228.html

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information