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
Description: PGP signature
