"Jonathan Dowland" <[email protected]> writes: > On Wed Feb 4, 2026 at 5:38 PM GMT, Andreas Tille wrote: >> 2.1. MIA team > snip >> 4. in case of no answer, the MIA team will make one manual attempt >> to reach the person, indicating that failing to get a response on >> that, the person's packages (if any) will be orphaned > > I'm a big fan of packages being team maintained by default. > > However, an ostensibly team-maintained package which is de-facto only > actually maintained by one developer, will languish if that developer is > MIA, and would not be caught by the above step. > > So as the ratio of team-maintained packages increases, the gain achieved > by orphaning directly-maintained packages as part of the MIA process > goes down.
Agreed. > Has anyone got any plans to try and identify and track such packages? 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. 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. The algorithm has to be a bit clever, it doesn't make sense for a package with version 1.0 released in 2010 and directly uploaded to debian in 2010 to be on the top of that list one day after version 1.1 is released. It should only count the number of days it lagged behind, which then would be just one day for this example. Do we have such a list somewhere? Another pruning would be to only include packages that ship something in /usr/*bin since I suppose those are the most important. /Simon
signature.asc
Description: PGP signature
