Re: unmaintained packages hidden by team maintenance (was Re: Bits from the DPL)

Simon Josefsson <[email protected]> Thu, 05 Feb 2026 16:14:15 +0100

Newsgroups	gmane.linux.debian.devel.project
Message-ID	<[email protected]>

"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 (application/pgp-signature, 1.2 KB)