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
Description: PGP signature
