Hi Tobias, thank you for sharing your experience. Its highly appreciated.
Am Sat, Feb 14, 2026 at 03:46:25PM +0100 schrieb Tobias Frost: > (the below is generalizing teams a lot. I fully agree that any generalization is inherently weak and that teams in Debian work in very different ways. > 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".) I would very much welcome this becoming the default way of dealing with such situations. > 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. I could imagine that the changelog author of any upload marked as a "Team upload" could be considered a team member. > 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. I fully acknowledge that identifying inactive contributors already consumes a significant amount of time and energy. Any additional friction in accessing reliable information will inevitably add to that burden. That said, I would greatly appreciate a pointer to any code implementing the "The proposed process will be as follows:" section referenced here: https://salsa.debian.org/debconf-team/public/data/dc25/-/raw/main/etherpad/txt/232-mia-team-interal-meeting.txt#L30-50 Despite my repeated questions about whether the implementation has started, I have not received any response. Even a short reply - either a link to the implementation or a clear "not yet" - would be helpful. At this point, I consider the lack of response a blocker to making progress towards a future process that is less draining in terms of time and energy. > 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) Shouldn't such a default removal of a former Maintainer be documented in the Developer's Reference[1]? If this is considered good practice, it would be helpful to make it explicit and visible rather than relying on implicit conventions. > 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 like. > But we'd need eventually someone to rehack on nm.d.o to make that > happen. Is there any concrete progress on this? Is someone currently working on it, or is this still at the idea stage? > 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. Could you (or someone else from the MIA team) provide concrete examples where the proposed automated process would be sufficiently error-prone that manual intervention is clearly required? I am not arguing against human review per se. However, it would help the discussion to better understand the specific scenarios in which automation is expected to fail, and what kinds of risks we are trying to mitigate by keeping this part manual. > 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. What about introducing an automated safeguard on Salsa: for example, downgrading an account to 'Guest' in all projects if it has not pushed any commits for a defined period of time (for instance, two years)? GitLab provides a feature to "Automatically deactivate dormant users"[2]. This seems like a reasonable way to reduce the risk associated with lingering accounts, while still allowing the person to regain access easily if they return. Such a mechanism could complement the MIA work by reducing the attack surface without requiring manual investigation in every individual case. > 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. I am strongly convinced that, in addition to the current procedures, we need a clearly defined orphaning process. While I fully agree that orphaning a package will not automatically attract new maintainers, it at least makes the status of the package explicit. Clarity has value in itself. An explicitly orphaned package signals that it currently lacks responsible maintenance and allows us to act accordingly. In particular, it may simplify decisions about removal if it turns out there is no compelling reason to keep the package in Debian. We already have a considerable number of effectively unmaintained packages. I consider it problematic that we often avoid formally declaring them as orphaned. I would very much welcome others joining me in defining a transparent and predictable process for orphaning packages. > Maybe we should more often also ask ourselfes if some packages should > indeed be retired instead of being tried to revived; +1 > ($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. Helmut has automated this process, and it works well for packages with long-standing RC bugs. That is definitely helpful and a step forward. However, we also have packages without RC bugs that are effectively unmaintained. The absence of RC bugs does not necessarily mean that a package is actively maintained or reviewed. In my view, such packages can still represent an attack surface within the archive. Leaving them in an unclear maintenance state for extended periods is therefore not only an organizational issue, but potentially a security concern as well. Kind regards Andreas. [1] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#how-to-salvage-a-package item 3. [2] https://docs.gitlab.com/administration/moderate_users/#automatically-deactivate-dormant-users -- https://fam-tille.de
