maintainer-list: make github, githubId mandatory fields
#273220
Conversation
Nixpkgs development takes place on 3 platforms: - GitHub: github.com - Discourse: discourse.nixos.org - Matrix: nixos.org server. As neither Discourse or Matrix are code-oriented platform, we usually expect _at least_ that maintainers are present over GitHub so we can mention them, interact with them via GitHub automation. In the future, we may revisit this and remove this restriction if we have an equivalent silo of data containing information about our own users which we can consume. In the time being, GitHub remains the only platform against where we can build identity authentication in the project.
RaitoBezarius
force-pushed
the
github-is-mandatory-for-now
branch
from
f12a1b6
to
6498631
Compare
There was a problem hiding this comment.
We already have a well-thought policy in which it was decided against more mandatory fields, even though the authours knew about the possibilities of GitHub. Before deciding on such a severe change, those who invented the existing policy should get the opportunity to review.
Furthermore, since this is decision very biased in favour of users of one platform relevant to the Nix ecosystem. Just asking those that actively use a GitHub account is expected to lead to a biased decision. We should have a way of considering Nix enthusiasts outside of GitHub, e.g. on Discourse or Matrix.
|
I mean yes, I am usually in favor of making those fields mandatory but if people really don't want to, then they just cannot log into that system. Would that be a problem? Also we might add a comment stating something in the direction of that if no sufficient ways of contact are added, then maintainer are invalid for certain things like security management. Edit: or we take it from a different direction: without a githubID you're entry is possible to name change squatting which is not acceptable for nixpkgs. |
|
@grahamc Considering that you wrote the current maintainer documentation which did not only work with optional GitHub entries, but even came with a vivid example of how to properly work with a maintainer entry that comes with no @ncfavier You also worked on the previous policy and added e-mail, while also clarifying that one of the communication entries would be mandatory. While clarifying some convenience features of consenting to a Personally, I regard it as counterproductive to further centralize the Nix* projects, but someone who was around longer might be better able to put this in the context of the long-term vision. |
Couldn't these concerns be coped with by providing a |
There was a problem hiding this comment.
Yes, I believe so.
- Official maintainers are surely expected to interact with issues and pull requests.
- People can still contribute even if not listed in
meta.maintainersanywhere, but not having a GitHub account seems like a much more significant obstacle when doing that than not being inmeta.maintainers. - It's possible to create a github account unlinkable to the person, I believe. (Well OK, github.com admins could be persuaded by police to log IP addresses, most likely, etc.)
infinisil
added
the
significant
Even then (and consider that European courts regularly consider the US as not providing comparable protection for personal data), there is the problem that when people add their Github account to their maintainer record, this creates the expectation that the maintainer will be reachable over Github. Now consider the developer travels to a country sanctioned by the US for some weeks. Github will then block the interaction (see e.g. https://www.zdnet.com/article/github-starts-blocking-developers-in-countries-facing-us-trade-sanctions/), and for the community the maintainer might look unresponsive and be kicked out of package maintenance based on existing policies. This cannot happen if maintainers are free to make their own informed decisions about how they can be reliably reached, because the decentralized options this PR wishes to devalue (Matrix, E-Mail) allow maintainers to choose a reliable hoster that isn't subject to the position of the US in the global political climate. Personally, I haven't faced such embargo situations myself, but I did notice Github notifications not reaching me as reliable as I would have expected, so I definitely don't feel comfortable with Github being made the default communication channel for responsibilities like package maintenance. I'd rather offer my help to make less centralized communication channels first order citizens in the Nix* ecosystem (e.g. NixOS/ofborg#663). |
Yeah we have just seen GitHub just dropping a bunch of notification subscriptions for one of the core Nixpkgs maintainers… |
There was a problem hiding this comment.
Just from a purely technical standpoint, this PR isn't ready to be merged. You'll need to update lib/tests/maintainer{s,-module}.nix to ensure that every maintainer has a github username/id. Then either backfill or remove previous maintainers that don't have one, or at least ensure it's being enforced for all future additions. Furthermore the docs in maintainers/README.md need to be updated.
From a policy standpoint, I think this is a significant change and should be properly discussed with the wider community at least on Discourse. And if there's controversy around this (which there already appears to be), then it would be more appropriate to attempt an RFC for this.
|
Let me just state that I did try hard to read and understand all your posts here, and retrospectively I'm sorry that I did. So much text, so little progress. I agree that there's no point in me participating anymore. |
Well, if you did read my posts, and then purposefully decided not to answer my question about an actual case of what your stating, and instead again and again came up with theoretical scenarios and accusations, then please don't be surprised if there is no progress. Next time you don't know of a case of what you're stating, maybe stay silent or just do a short "no, it hasn't actually happened yet". I feel sorry about the other participants because it really makes the whole PR hard to read if we need 8-10 messages just to figure out you weren't talking about real issues. I asked about empirical evidence for something which affects multiple maintainers (see #273220 (comment)). You immediately made this a "discussion" solely circling around accusations against me (#273220 (comment)). Really, if you have personal issues regarding my person, send an e-mail/Discourse message/anything, but let's keep public discussions constructive. |
|
As the maintainer of the gnome extensions, I regularly get some emails to my Nix mail address reporting issues. Most of the time, if I cannot resolve it immediately, I tell those people to open an issue on GitHub instead. Because (ignoring the fact that IMO all communication which can be public should be public, and that private emails are not) we do have a centralized place to track issues, and any deviations from that just create additional effort for everybody involved. I now have to go and check my mail reports against existing issues, for example. I do not have a built-in way to track which issues are completed or not in my mail folder. Therefore, IMO, saying "well one way to contact me should be sufficient" doesn't really cut it. If I'm writing an issue and I see that one of the maintainers has no GitHub handle there, the truth is that I simply won't contact them in that case. Which is a problem to the task of being a maintainer. And even if I did reach out, then there still would be the split where all the relevant information is on GitHub, and all other communication is private, and one needs GitHub to interact with that issue. Therefore I'd argue that yes, any maintainer currently must have a GitHub account. Now as to the question of whether or not that GitHub account should be mandatory in the maintainers list. Well, I am currently not convinced by any of the alternatives brought up so far. Because with the example of I also honestly fail to understand the objections to this policy, apart from the governance arguments on this PR which I won't go into because I have nothing to add to that discussion. If you don't want you personal GitHub account linked with being a Nix maintainer for whatever reasons, then just make up a burner account like some other folks. We don't have any stupid "real" "name" policies or anything, we just care about having a handle to ping on the platform where the work happens. If the issue is that some people just don't want to interact with GitHub, then the unfortunately this currently is incompatible with our development workflow. |
For many years, this was not supposed to work (although it might happen). So if there are reasons for this to work, you should probably open a feature request. Anyway, if pinging maintainers that use e-mail seems to be a problem, this is a script that do a basic ping that could be processed by a MTA with pipelining support: https://codeberg.org/gm6k/nix-maintainer-tooling/src/branch/main/mail-maintainers.nix |
|
So my honest impression reading the conversation on this PR is that we are now going round and round with the same arguments being repeated again and again, and we have seen all the different positions on the matter. I don't think we are actually going to have different feedback discussing this on other platforms or opening an RFC for this. The other matter that have been discussed a lot and that is not in the scope of this PR is: How can we improve our tooling and contribution model to allow for the most inclusive contribution process and not force people to rely on github while not inflicting further energy drain to our contributors? This question should indeed continue to be discussed out of this PR for example on discourse or matrix so that we can adopt long terms goals in that area. |
The point of the RFC process and community governance more broadly is specifically to avoid this type of decisionmaking. |
Also, define core contributor. |
It is my experience and was also confirmed in this context that for contributions above a certain level of complexity, you'll get asked to also join maintenance. So I do assume that the possibility to contribute would be degraded by this PR. I might reconsider if someone confirm that none of the contributions coming from affected contributors (see at least #272199 and #178656), including PRs to add packages, would not be put at a disadvantage if it goes through. Edit: Since I would be affected, I asked @RaitoBezarius to specify what role as a contributor would still be left for me after the change goes through (effectively meaning that my maintainer entry would be technically invalid). This is important for me because I contribute packages for which I gladly take the maintainership responsibility, and work on updates for complex to integrate packages like TensorFlow, for which I also consider offering maintainership since other developers seem to trust my expertise on it. So I fear the PR would degrade the usefulness of Nixpkgs for me. @RaitoBezarius however refused to provide me with a clear answer on what I would still be able to do (#273220 (comment)), instead replying with a lengthy text containing subtle accusations of working with me being hard (which is something which I haven't experienced in my contributions referred to above). I think it would be only fair if the other affected contributors and me could at least be informed about the actual effect this PR would have on our interaction with Nixpkgs.
I'm not sure what you're getting at. Do you compare the requirement to subscribe to the mailing lists to a requirement to subscribe to GitHub? If so, then I'd actually disagree. Subscribing to the kernel mailing lists does not come with a additional contractual overhead as they are also provided by the Linux Kernel Organization kernel maintainers have (and likely want) to deal with anyway. GitHub is a separate legal entity bringing in its own incentives and requirements. I would actually doubt that the Linux kernel developers would happily agree if someone would announce they all have to become customer of some random company in order to continue working on the kernel. Besides - young developers who never had to touch an e-mail address might not know that - the Linux kernel development went through almost exactly this about two decades ago when they went for a commercial versio control platform (BitKeeper). They had to learn it in the painful way what it means when their main development platform is subject to commercial interests of some for-profit company, and that company being willing to provide the service "for free" initially did not make it better. The result of this process (Git being developed) is something we all are happy about now. But we at Nix* can avoid that stressful part, and head directly towards writing the tools we need to solve our problems technically.
Obviously these expectations you talk about are subjective, and since a few people here opted to discuss the topic only on GitHub, it should not surprise that we see many voices who agree. It's always easy to expect that everyone should act the same way as oneself. We already have some maintainer responsibilities documented, but they go as far as allowing maintainers to be unresponsive for three months. Personally, I'd think if we want to fiddle with maintainer responsibilities, reducing that time and/or creating fallback maintenance mechanisms might increase the quality and seamlessness of collaboration more than trying to enforce how maintainers communicate.
GitHub's reliability is all but besides the point here. The whole argument is about the theory that Github-only will improve the reliability of maintainer communication. As someone who experienced GitHub reliability issues multiple times, I would argue that the opposite is the case: If we want more reliability, maintainers should be able to choose how they can be reached most reliably, and of course take responsibility for that being the case. This is something which is limited for GitHub, because you always depend on GitHub. For the E-Mail or Matrix options we have for multiple years, maintainers can just switch their provider if their current one is too unreliable.
I don't think it's about GitHubs Git hosting itself, but the communication and collaboration platform they built around it. Developers can and do use GitHub's cheap Git hosting and still communicate and collaborate over different channels. And the effort to facilitate this is already in place. So I see no point in locking out other developers just because they prefer different communication channels. Obviously their choice did not hinder their patches to reach the GitHub-based hosting, otherwise these maintainer entries wouldn't be there. |
I'm blocking this PR from being merged mainly because it's not ready from a technical perspective, see #273220 (review) |
|
Ok. Let's just drop users without githubId than. Without this information they won't get pings on pull requests anyway, so this information is not very useful. Those extra eval checks hopefully don't take too long to implement. |
The other data in maintainers list is being used by humans, though. «Let's just consider the main use case and deal random damage to all the other use cases» |
|
Has it already been discussed to only enforce this for new maintainers? |
|
Thanks for your contribution which is insightful, but there might have been some mixup between different issues:
Understandable. I would do so similarly. Or, if they don't have an account on the issue tracker platform, I'd probably offer to open the issue myself in order to keep track.
I don't understand why you would be forced to do so. The Is it possible that all this recent aggressive campaigning against e-mail users was just because of the misconception that those who prefer GitHub should be forced to enter an e-mail address?
Well, exactly this kind of boycott could have less negative impact if we had the suggested
This is already untrue with our current limited bridging solutions. If someone needs to interact with a GitHub issue and neither has access to a GitHub account nor knows someone who could help, it would still be possible to reference the issue on Discourse, having Fundamentally, I would agree about information to be public, as it makes things easier to be able to index all kinds of reports and easily find everything later. But there will always be users who do not want their issues with the software to be public. I think it can only improve the professionality of the Nix* ecosystem if users aren't forced to make all reports public. In an ideal world, every maintainer would be able to supply both a public and a private contact, giving users the choice. Until we get there, it doesn't make sense to attempt some kind of monoculture.
I understand that you would not want to have that extra step in between. This is perfectly fine, and as written above, you're still flee to only provide a GitHub handle. But just because you prefer this for yourself means that every other maintainer does have to interact exactly like you prefer? Nix* has always been a heterogeneous ecosystem. People like to run different kernels, CPUs, libraries, application software etc. People improve different areas of the whole ecosystem. I honestly don't think that this ecosystem will be improved by trying to eliminate other participants from it just because they have different preferences.
I asked about throwaway accounts already before when it came up (#273220 (comment)), but didn't get a response. I might ask GitHub whether they would be ok with that. Still, requiring a throwaway GitHub account comes with a contract overhead because an account not being used still requires to accept GitHub's terms. So, IMHO the cleaner solution if there are no expectations to that account anyway would be to allow a As long as there is a real and operated GitHub account associated with a maintainer entry, that maintainer person will always be associated with the GitHub account, and would be made responsible if the GitHub account works unreliably. So anyone who experienced GitHub reliability problems before and cares about reputation would have good reasons to prefer a different way of being contacted. If all you care about is having a handle to ping, then the suggested |
|
I suspect this will not be merged as-is so I am making a decision to close it. The RFC process is seemingly where this should go, maybe even with some more clearly defined expectations and guidelines for maintainers outside of points of contact. Feel free to reopen if you think I’m wrong. |
|
Since there were only two accounts effecting this, why do we need go to through the RFC process? We are already almost living this and this just puts that into the rules. IMO the RFC is way to overblown for this change and it will only take longer and make everything more complex. |
|
@SuperSandro2000 There were another ~50 maintainers without GitHub accounts last year before #178656 |
I count only 4 entries where we added a githubId in the PR? |
|
Yeah, Most of the changes done in that PR were fixing casings of GitHub display names and removing inactive accounts (which should also probably be removed from the nixos org). |
|
@Lassulus I count 4: https://github.com/NixOS/nixpkgs/compare/d7b32a0fc41d0ea2e7c3f6a602d417476c8d3c63..0f55ab1bbc027d66c6aa3c21b3aae41bfd3e6c36?expand=1, but yeah not a lot. But it also removed 50 maintainers without github accounts from the listing:
I guess it's hard to determine whether somebody is still active when we have no associated github account though. That sounds like another good reason for making it mandatory. |
Experience shows that checking for activity (the docs say 3 months) isn't reliably done before removing maintainers. If we want to do it, accounts with Discourse linked (see #275059) could work equally well. |
|
This seems to be a heated discussion, and many of the responses are so long and wordy I had to use GTP to summarize and make sense of them. As i see it, this is an overview of the explored problem space: EDIT: Concerns were raise to me about the problematic use of LLMs. For this i apologize. All that follow is my own writing however. 1. Some maintainers want to be anonymous/forgotten:a. Accommodating new maintainers who refuse to provide any means of contact:
b. Some maintainers may want to remove all means of contact from
c. Some maintainers may invoke the GDPR right to be forgotten after having contributed to nixpkgs.
2. Some maintainers refuse to link a GitHub account, but are willing to provide other means of contact:This prompted a heated discussion, boiling down to two and a half options: a. Require a GitHub account
b. Require at least one means of contact
c. Don't make a choice on policy and instead provide an alternative contribution channel as discussed in 1a |
And there is no easy way to just ping them on GitHub to, contact them or request them for review. Contacting them over private chat somewhere else makes the conversation impossible to follow by other people and puts additional strain on reviewers. |
This reverts commit 3429e79. GitHub names/ids are not mandatory for now. See NixOS#273220, NixOS#272199 and NixOS#273146. Furthermore this user has not consented to their account information being added to the listing. While we can't reasonably change the git history, we can revert the change so it won't be included in future revisions.
This reverts commit bc0adb2. GitHub names/ids are not mandatory for now. See NixOS#273220, NixOS#272199 and NixOS#273146. Furthermore this user has not consented to their account information being added to the listing. While we can't reasonably change the git history, we can revert the change so it won't be included in future revisions.
Description of changes
Nixpkgs development takes place on 3 platforms:
As neither Discourse or Matrix are code-oriented platform, we usually expect at least that maintainers are present over GitHub so we can mention them, interact with them via GitHub automation.
In the future, we may revisit this and remove this restriction if we have an equivalent silo of data containing information about our own users which we can consume.
In the time being, GitHub remains the only platform against where we can build identity authentication in the project, otherwise, such automation cannot be built or must exclude any maintainer who doesn't contain the right field.
At the moment, I do not believe it is the project's priority to pursue opening contributions from external platforms to GitHub as we do not have the tools neither the bandwidth to handle them.
As an example of usecase, the security tracker we are building in https://github.com/Nix-Security-WG/nix-security-tracker/ we have a need for logging via GitHub and we cannot build a local account silo (it doesn't really make sense), neither I feel like imposing myself on the infra team to maintain a LDAP or a directory of accounts. Therefore, GitHub login is the only solution we have here. Furthermore, permissions are really stored in the GitHub data silo rather than in any of our other platform.
Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.