On Thu, Feb 05, 2026 at 04:14:15PM +0100, Simon Josefsson wrote:
But why would that matter? Presumably if there are serious problems
with a team-maintained-but-really-one-person-doing-the-work-package,
when that person goes missing, anyone else from the team can step in and
fix it? And if nobody else from the team takes responsibility, it is a
team-wide problem that MIA probably cannot resolve.
Or are you thinking of finding out which maintainers just stopped
working and the packages doesn't have any serious problem, but several
versions behind? In well-working teams, I would think that someone else
would just step in and feel at liberty of updating the package at some
point. This approach works well in the Go team, in my perception.
We have a lot of such cases in the Python team. I think generally
speaking we function reasonably well as a team, but there's a huge pile
of stuff to do and only so many hours in the day. I do quite often find
that the alleged Uploader is somebody who last touched the package in
2016 or something like that. Updating the package once we notice this
isn't normally a huge problem, but it does mean that things will
probably have been lagging behind for some time until somebody notices.
Perhaps a tool that finds a top-list of the "worst" version laggers in
Debian would improve this? That is, sort the set of packages which has
been behind upstream's latest release for the longest time.
I wouldn't be 100% confident that something like this doesn't exist
somewhere - sufficiently clever filters in UDD, say - but if it does
then I've missed it and I would find it helpful.
--
Colin Watson (he/him) [[email protected]]
