On Thu, Feb 19, 2026 at 08:55:26AM +0100, Simon Josefsson wrote: > Tobias Frost <[email protected]> writes: > > > On Tue, Feb 17, 2026 at 11:34:31PM +0100, Simon Josefsson wrote: > >> It seems there is some support to make Uploaders optional, so I made a > >> patch to move this into the realm of actionable: > >> > >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798476#462 > >> > >> Has there been any strong opinions to not make that change? > >> > >> I see valid arguments about this diluting the ability to find real > >> humans behind a package, but I think this can reasonable (and more > >> accurately) be resolved by deferring to debian/changelog fields and/or > >> the PTS history on who made uploads. Making the field optional does not > >> forbid anyone to continue using it for what they believe it is useful > >> for. It just makes it possible for people to stop using the field when > >> they don't feel it provides value > > > > I think the key point from the MIA perspective is that our workflow is > > person-centric. > > Thanks for explaining! > > > We usually start using that informatin when we've determined that > > specific person became inactive or unreachable, and then need to > > determine which packages might be affected. Upload history helps to see > > past activity, but it does not reliably answer the question "which > > packages do we need to look at because this person was involved?" > > Why not? I think commit and upload history is a good indicator. > > Commit and upload history seems to me be the real indicator of where > actually work happens (or not happens). Isn't this information > available in UDD or some similar resource?
Activity data is certainly useful to assess where work has happened. The question from the MIA perspective is slightly different: once a person has been determined inactive, how do we obtain a reliable and complete list of packages that may require follow-up action because of that person’s involvement? Do you have some concrete query in mind that you could share with me, which would tell (quickly and with accuracy) that someone stopped working on a package and we need to tell someone, e.g a team? What other resources do you think could help? > > in other words, the information in the Uploaders field is less about > > determining activity and more about enabling action once inactivity has > > been established. > > > > If team membership is not clearly documented, we cannot easily > > determine which team should be contacted when someone goes missing. In > > practice, that would mean teams would need to notice emeritus/removed > > cases themselves and act accordingly. For DMs and DCs, we do not even > > have comparable notifications. > > > > The Uploaders field is not perfect, but it provides a simple and > > queryable mapping from person to packages, which is exactly what we need > > when starting to clean up after a missing person. > > I don't understand this part. What is the cleaning up action you are > thinking of? Is it removing the MIA person from the Uploaders: fields? > > What else is there to do when someone disappears? Orphaning and asking to remove persons from the uploader is possibly the effect that has the most visibliy to the project. Removal from Uploaders is only one possible action, and I'd say the current goto mean to effectivly acilitating maintainership transitions (e.g. orphaning, helping identify new maintainers, or contacting relevant teams), and coordinating with other teams where project resources are affected.¹ For that, we need a person -> package mapping that is predictable and queryable once inactivity has been established. ¹ usually people start missing people because of neglegted packages and then trigger us. I expect when Uploader is no longer widely used, people will also less likely to ping us. (The “MIA 2.0” process would make MIA work independent of triggers, but we are operating with the old process) > Making the field optional and allow not putting humans in it seems like > it may save everyone time to have to keep track of MIA's and removing > their name from a control field. It may reduce metadata maintenance for maintainers, yes. From the MIA side, however, that cost does not disappear, it shifts. Instead of updating a structured field at the time of change, we would need to reconstruct person -> package relationships later from activity data when cleanup is required. Maintaining the Uploaders field is comparatively cheap and distributed: it is updated when work is already happening. Reconstructing associations after someone has disappeared is necessarily centralized, heuristic, and more time-consuming. The DPL recently described inactivity as a structural challenge for Debian, particularly the lack of lightweight and reliable ways to make changes in availability visible. Explicit and queryable person -> package associations are one of the few structured signals we currently have at the package level. The more systematic inactivity workflow discussed at DebConf (I've nicknamed it "MIA 2.0" earlier) outlines a possible activity-based model, but it remains conceptual and is not operational today. Until such a replacement exists in practice, removing explicit associations would not merely simplify a control field; it would change how inactivity is handled, without a defined alternative. MIA 2.0 will still include "cleanup" steps, but these become less critical for the project if we move toward an activity-based model, supported by complementary processes such as easier ways to orphan or take over packages that may be neglected. Maybe, once such a system is in place, it could even allow us to drop the Uploaders field?² -- tobi ² "?" because honstely I can't tell at the moment, too many loose ends.
signature.asc
Description: PGP signature
