maintainers: drop gm6k

[SigmaSquadron]

Although this maintainer has responded to requests for maintainance and is active in Nixpkgs, the new data collection requirements introduced in #437085 have been a privacy concern for this maintainer, who has stated
(#437082 (comment)) that they do not wish for their data to be added to the maintainer list.

For this reason, there is no other recourse than to remove this maintainer's information from newer revisions of Nixpkgs, as their maintainer entry is now non-compliant with Nixpkgs' latest policies. Once more, this removal is NOT due to the usual inactivity reasons, but for specific privacy concerns expressed by the maintainer being removed.

The maintainer in question has already expressed his wishes in #437082.

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

---

Add a 👍 reaction to pull requests you find important.

[qzylinra]

It might be better for the maintainer to proactively open a PR to remove the maintainer entry.

[SigmaSquadron]

They had seven days to do so. They opted to express their wishes via a comment instead, and that must be respected despite it not being in the form of a pull request.

[wolfgangwalther]

In #437082 (comment) they were given the choice. He made it clear in the following comments that he's not going to add github data to his maintainer entry.

[nixpkgs-ci]

Backport failed for release-25.05, because it was unable to cherry-pick the commit(s).

Please cherry-pick the changes locally and resolve any conflicts.

git fetch origin release-25.05
git worktree add -d .worktree/backport-439407-to-release-25.05 origin/release-25.05
cd .worktree/backport-439407-to-release-25.05
git switch --create backport-439407-to-release-25.05
git cherry-pick -x 81d1a3a2ae011634dc663816c72f4acf8c63c22f

[zeuner]

It's exciting to see that PRs get merged way faster than in the documented 7 days, within a few hours, thereby effectively preventing affected maintainers from reviewing.

I understand it's important for you to quickly remove people who get in the way. Still, I would propose not pushing inaccurate information into the commit history, even more if it the inaccurate information relates to a natural person.

In this case, it was repeatedly stated that the concern about having the GitHub handle added to the maintainer entry is related to ensuring reliable maintainer communication. GitHub based notifications have been unreliable every now and then, and it has even been shown that GitHub based communication can be deliberately hindered by other users. To ensure that the maintainer can be reached reliably, providing only contact details where reliability can be ensured seems to be the only effective way, since adding less reliably channels (like a GitHub handle) can lead to situations where people actually use them, resulting in a bad user experience because they think they cannot reach the maintainer.

The data privacy regulations present in various jurisdictions might be the most promising way for maintainers to defend their right to provide the most reliably communication channel. Still, it's inaccurate to claim unexplained "privacy concerns", and doing so can result in misunderstandings.

[pbsds]

#437082 was open a week before, you had ample opportunity to fix your maintainer entry.