Hi, On Mon, Feb 09, 2026 at 01:08:23PM +0100, Andreas Tille wrote: > Hi Sean, > > Am Sun, Feb 08, 2026 at 12:54:41PM +0000 schrieb Sean Whitton: > > > > No, it was the MIA team who were opposed to us making that change, > > nothing to do with the FTP team. Their workflow would have been broken > > by the change and they weren't happy with the alternatives. > > Can we review this opinion with the (remaining) MIA team (in CC) in the > light of the proposed (changed) workflow?
Thanks Andreas for explictly involving us. I do not have the time to have thoughts on every aspect in this thread, but I'd like to share at least some of my thoughts I have. Please appologize if I do not engage in deeper discussion on this, due to my time availability. - uploaders / team mainaince (the below is generalizing teams a lot. There are teams that are very well organized and we've never had issues with; We've got agreements with some teams how to handle their retirement cases and that worked well; but those teams are usually not sources of concerns for the MIA team; usually those agreements are in the line of "don't file bugs, send us a mail that someone went missing and we'll use our automation to update the Uploaders file".) The uploader information remains very valuble. A key problem is that there often no information on who is part of a team, assseing if a team is functioning well is often hard, whether all (to us unknown) team members are already gone -- if the team is actually still teaming… Teams a very hard to assess for the MIA team. I wrote (smaller) teams emails as part of MIA work but often did not received any response. Being able to adress a *human* is IMHO much more promising of getting results - as often they feel more resonsible for their package - than talking to a team. Hunting information about no longer active persons is already taking a lot of energy and time. Any additional friction in accessing accurate information will increases that burden. On the other hand, please don't keep everyone in the Uploaders field, limit them to only those actually working on the package; please do some Uploaders-Field-Hygene from time to time. For example, if you do an ITS, and the maintainer didn't response, it is IMHO fine to remove them by default instead of keeping them; (as this can easily be undone at any time and could also be communicated this way to the former maintainer and/or checked with them beforehand, with the default to removal when there is no answer from them within some reasonable time) Outside of ITS, the human in the Uploaders field is likely the one that is most able to judge whether the other humands are still signal or already noise. (Please aim for a high SNR.) Luckily there were disussions in Brest to reform the process to a more automated way, and we've got an rough idea how it could look likke. But we'd need eventually someone to rehack on nm.d.o to make that happen. But the process is on-purpose not automated end-to-end, if just helps to filter out the "false-positives", for my lack of better words atm. After the automation finished, there will still be humand needing to look through information manually, where likely we'll need above information readily available too. That's last paragraph is orthogonal to team and uploaders, of course, as it likely won't cover teams as as outlined above we don't really have the information to track teams. As a side note: contributors who neither maintain packages nor list themselves in Uploaders are basically invisible as there will be no trigger for us to investigate. Being invisible can be a problem as those people still have access to all of our infrastructure, part of the MIA mission is to keep Debian safe from misusing lingering accounts. Maybe the automation needs to be different, like an regular membership ping? (like done in the past for DMs)? - undetected, unmaintained packages, reviving those packges We are also lucky that we now have the ITS procedure as helps to transit ownership to interested people more easily, this often reduces the immediate need to have action on a maintainer. As this was a topic in the recent past, I think the MIA teams stanca still is that orphaning packages is last-resort, when everything fails. Orphaning packages will not automatically attract new interested maintainers, nor make them maintained again. OTOH if you orphaning too careless, you might alienate the person. Maybe we should more often also ask ourselfes if some packages should indeed be retired instead of being tried to revived; ($people, including /me have done so in the past with a RC bug saying, "hey respond to this bug, or I'm gonna RM this package in 3 months" on really carefully manally selected packages that likely noone will miss. There is no silver bullet… -- tobi (as MIA team member, but speaking for himself only)
