Re: Thoughts on removing access to the Python teams repositories to inactive members ?

Nicholas D Steeves <[email protected]> Mon, 19 Jan 2026 23:04:36 -0500

Newsgroups	gmane.linux.debian.devel.python
Message-ID	<[email protected]>

CCing MIA team in case they have a script that does what we're
discussing, and because stale-Gitlab-account detection seems like
something they might be interested in.

Thomas Goirand <[email protected]> writes:

> On 1/17/26 11:42 PM, Nicholas D Steeves wrote:
>> Thomas Goirand <[email protected]> writes:
>>>
>>> BTW, as a Salsa admin, I thought that maybe, we should do the same
>>> thing globally: at least *lock* inactive accounts with the rule:
[snip]
>>> Anyone to help me to write such a shell script? :)
>> 
>> Maybe base it on the GNOME project's Gitlab script?
>
> Where to find it?

Sorry, I don't know; maybe someone on the GNOME team does?  Also, I'm
assuming upstream GNOME's Gitlab has a script...  Meanwhile, if GNOME
and KDE (which I just learned also switched to Gitlab) don't have a
script, and we all pay for non-free Gitlab, maybe Gitlab would be
willing write this feature if all of us write to Gitlab?  It sounds like
we want:

  1. A function that will output a data structure that contains all
  accounts that haven't been used for an activity during a period; this
  function would check messaging, MR review activity, commits, etc.  And
  we want for a namespace/team admin to be able to query activity for
  that namespace/team.  Should the global scope be salsa admin[s] only
  (ie: maybe it's too resource-intensive)?
  2. Filter that list to exclude accounts like an ACL like DD.
  3. Ideally have a nice interface with checkboxes?
  4. Notify user and give the user a chance to reactivate account to
  active status.
  5. Maybe this feature could remind about MRs too, and/or be folded
  into some kind of stale-notify-decruft-section functionality?
  6. Maybe run it as an scheduled job?

Alternatively, this seems like a nice defensive policy to have thing for
any Community Gitlab instance, so maybe the larger community would like
to work on this together?  Maybe they already have?  Does this sound
more like a leadership by example thing like reprobuild, or like a
Debian working with other projects and communities for better policies
and tools in an era of supply chain attacks?

Cheers,
Nicholas

signature.asc (application/pgp-signature, 857 B)