@handle in lib/maintainers.nix must be a github username

[domenkozar]

For sake of communication, handle used in lib/maintainers.nix should be the handle of person behind his/hers contribution on github.com.

This is the first step of implementing #13602 and showed up as a problem in #18209 .

I'd like @NixOS/nixpkgs-committers to address this in master branch, I'll write a script that checks if this rule is respected.

[shlevy]

👎 from me. We have some in the community who don't like github's proprietary nature and submit patches via ML, and sometimes your nick of choice isn't available/appropriate on github (e.g. eelco vs edolstra). I'd much rather we annotate maintainers.nix with optional github username info, or at least have a way to say github-name = null or github-name = "something-else" and default github-name to the attribute in maintainers.nix.

[domenkozar]

We have some in the community who don't like github's proprietary nature and submit patches via ML

Sure, those who're not registered on github can have a nickname they'd use somewhere else.

sometimes your nick of choice isn't available/appropriate on github (e.g. eelco vs edolstra)

That's the unfortunate nature of primary keys, but you still a nickname on github. We could introduce an attribute set with github nicknames, but do we really want to maintain so much complexity and communication overhead? We'll end up with a hashmap of usernames for each contributor, that's plain insane.

Our platform for development NixOS is github. There's no way to deny that, we can just embrace it better.

[7c6f434c]

We have some in the community who don't like github's proprietary nature and submit patches via ML

Sure, those who're not registered on github can have a nickname they'd use somewhere else.

sometimes your nick of choice isn't available/appropriate on github (e.g. eelco vs edolstra)

That's the unfortunate nature of primary keys, but you still a nickname on github. We could introduce an attribute set with github nicknames, but do we really want to maintain so much complexity and communication overhead? We'll end up with a hashmap of usernames for each contributor, that's plain insane.

Have you seen my vanity counter script? All possible combinations of
unfortunate events do happen, including change of GitHub usernames for
obviously the same person.

The true nature of primary keys is: you control them completely, or
there is no hope.

So yes, I think we want to keep the handles and add translations
as-needed, it is less insane.

[shlevy]

Why a hashmap of usernames for each contributor? We have email, and my suggestion is that we add github which defaults to the maintainer attr but can be overridden if desired. If we ever come to rely on yet another service where we need to associate people with usernames, we will need to add another attribute in either case, except for those lucky enough to have the same github username as username on the new service.

[shlevy]

So maintainers.nix can be either:

foo = "bar@example.com": github username foo, email bar@example.com
foo = { email = "bar@example.com"; github = "baz"; }: github username baz, email bar@example.com
foo = { email = "bar@example.com"; github = null; }: No github username, email bar@example.com

[shlevy]

Our platform for development NixOS is github. There's no way to deny that, we can just embrace it better.

When we switched to git, a major concern was relying on github and it was decided at the time that people could develop via ML instead, and indeed some do. So yes, I think you can deny that github is our only platform for development, though of course it is the main one.

[domenkozar]

OK, sure. You can't take something from a person that was already once given :)

[shlevy]

(FWIW, I personally don't share the concerns people have about github, but I think we should respect them given that it's not a significant burden to do so)

[zimbatm]

Maybe we should define the responsibilities of a maintainer. If a maintainer should handle issues related to his package, and github is our issue tracker then it means having a github account is a requirement. And people who want to contribute patches on the mailing list can't become maintainers (but can still contribute patches and need to find another maintainer for new packages).

If that doesn't work then we have to either relax the responsibilities of the maintainer or change issue tracker.

[shlevy]

Personally I don't see a problem with users emailing maintainers (cc'ing the ml) who aren't on github. But I can understand why some would see that as a burden.

[vcunat]

I personally find it very comfortable to use @mention whenever I see maintainers.mention, without having to lookup anything. I know only about a single regular contributor who doesn't have a github account.

[benley]

I also really appreciate it when handles match github usernames, but if we're not going to require that they match, something like shlevy's hashmap suggestion seems like a decent compromise. Perhaps in conjunction with a .mailmap file?

[fpletz]

Alternative solution merged in #36119.