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

Simon Josefsson <[email protected]> Thu, 05 Feb 2026 18:22:13 +0100
Newsgroups	gmane.linux.debian.devel.project
Message-ID	<[email protected]>
Colin Watson <[email protected]> writes:

> 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.

Do you (or anyone else) update the Uploaders field?  In what way?

For Go packages I don't bother to update Uploaders: even if I happen to
be the uploader of the last 5 uploads, and my perception is that nobody
else bothers either, so packages rarely change Uploaders:.  I'm not sure
if there is any policy or recommendation on this, and I hope nobody in
the Go team feels strongly that nobody should touch "their" Go team
package.

I don't find this problematic, since I mostly regard
Maintainer/Uploaders fields as a source of problems, but maybe someone
has suggestions what a good process for updating Uploaders: fields for
team packages.

>>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.

I wonder if UDD stores upstream release events, which is necessary to
generate a "correct" list.  Maybe a list of the oldest packages in
Debian that has a new upstream release is a useful enough list to start
with.

/Simon
signature.asc (application/pgp-signature, 1.2 KB)