treewide: remove srgom

[AndersonTorres]

Description of changes

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[AndersonTorres]

Pinging @SRGOM

#290642

[dotlambda]

Should they also be removed from the maintainer list?

[AndersonTorres]

I prefer to do this in a future batch.

[doronbehar]

I prefer to do this in a future batch.

It makes sense a bit more to me to do it per maintainer. Other then that, this is good to go. Let's give @SRGOM a few days to respond. If days pass, cc me to merge this if I forget.

[AndersonTorres]

Sometimes some packages are maintained by multiple silent maintainers. It can create some strange dependency trees.

Other times some packages are being modified on Staging.

Further, some people want to adopt some packages, and I prefer to detach them so that they cam be adopted independently.

Because of this and other minor annoying things, I prefer to delete entries in maintainers set a bit later.

[bendlas]

Closing these removal PRs, since they are not grounded within community consensus. See #337478 (comment)

@SRGOM be sure that we value your involvement and any time you may have to spare, helping with the packages you're maintaining and others as well.

[SuperSandro2000]

That account has been inactive for 4 years. It can be removed with no bad feelings.

[bendlas]

That account has been inactive for 4 years. It can be removed with no bad feelings.

The other PR got a bit hectic, so one could be forgiven for not reading all the way through. So again here in simple terms:

I'm not opposed to getting stale maintainers out. I am opposed to doing it the way it's being done in these PRs.

More on the new PR you opened, but the gist is: At that rate you could have just re-opened this one ...

[SuperSandro2000]

GitHub doesn't allow me to reopen this PR, so I opened a new one.

[superherointj]

I'm not opposed to getting stale maintainers out.

Okay...

I am opposed to doing it the way it's being done in these PRs.

You are only opposed to the wording of the description of the pull request, correct?

Since the PR content was right then. You should have never closed all these PRs, without asking first.