On Tue, Feb 17, 2026 at 09:05:08AM +0100, Andreas Tille wrote: > 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.
ACK, but as said, there is no issue with the "good functioning teams". It won't scale for teams where we cannot rely that they will act on the bugs we are filing. (If you look how many "remove from uploaders" bugs are still open/unhandled since years, should get an idea… if we would just mail that team alls those "remove from uploader" will get lost. As written elsewhere in the thread, people are reluctant to remove uploaders, they will be more reluctant if the triggering bug is not there. > > 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. Changelog entries are not very accessible to assess this information quickly, also, where do you cut off the information to say they are no-longer-teammembers? > > 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. The above has not been implemented, and I fear that all the persons be able to do so are quite too busy. (The code for nm.d.o is on salsa, if someone wants to take a stab) IIRC the data source for the new tool was supposed to be contributors.d.o > > 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? Not to my knowledge. > > 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. (I think you will know with the first failure.) One likely failure mode is that the data source will be incomplete, there might be corners we are not looking properly. I think contributors.d.o does not look at salsa, for example. The MIA's mission was always to be 10000% sure before forcefully removing someone from the project. During the Brest session there was actually a push for a bit more automation, but the room rejected that idea. (to be clear a bit more, not complete automation), this is also visible in the BOF notes you linked. > > 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. (If the salsa admins think that is sensible thing to do, they should. Especially for contributors not having any status or only little contributionn or even do not show up on c.d.o at all) > > 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
