treewide: fix unexpected nixpkgs data scheme breakage #272199
Conversation
This is the only team in nixpkgs that unfortunately broke the maintainers schema.
github/githubId was missing.
github/githubId was missing.
RaitoBezarius
changed the title
|
Nice fix. Would it make sense to add proper validation/typesafety for meta? Or is that a quite significant overhaul? |
|
I think that's doable but can introduce perf penalty, we have ofborg for that and checkMeta |
|
Ah ok. So that should for the most part avoid this in the future? Is checkMeta blocking or just advisory? |
ofborg
bot
added
10.rebuild-darwin: 0
It's "blocking" from OfBorg perspective but in GitHub, you can bypass it I guess. |
| maintainers = [ teams.ororatech ]; | ||
| maintainers = teams.ororatech.members; |
There was a problem hiding this comment.
checkMeta checks for a list of attrs, not a list of maintainer entries.
There's a todo to use the maintainer type
nixpkgs/pkgs/stdenv/generic/check-meta.nix
Line 310 in 70475eb
|
I will send this in the meantime to stop the evaluation outputting violation of the schemas. |
|
Successfully created backport PR for |
|
Maintainers not entering data into every optional (see https://github.com/NixOS/nixpkgs/blob/master/maintainers/maintainer-list.nix#L7) field is not a "data scheme breakage", but an application of Europe's GDPR law and similar legislation in other countries. Please be absolutely sure you have the consent of the affected people before adding personally identifying information into a public repository. |
I am surprised that you are employing GDPR law towards that mean, your information was publicly available in the commit history. If it's not possible for you to add your GitHub account which you are using to contribute, I'd advise considering contributing by sending patches via email to another contributor who can pick them up and removing yourself from maintainers as it makes it quite difficult to integrate you. If this was an optional field, I can send the changes to make it mandatory and uniform. |
GDPR is exactly about making sure that information found somewhere will not be arbitrary used an different ways not expected and/or wanted by the person that published them. I'm not sure why
I'm surprised to see When my entry was added, I explicitly stated that I want to keep control over how to contact me in context of maintainership. I received positive feedback about that and it was added. So it's surprising that there is now a rather strong urge to surpass what was consented to earlier. I can offer an (also optional) Matrix handle if it helps.
I guess the people who decided about making everything apart from the name optional had their reasons for it, so why change it? It's not an improvement to increase dependence on GitHub, so it was a very reasonable decision to allow maintainership even for those who plan to move away from that platform. |
|
@ncfavier As you defined to what extent the fields are optional (https://github.com/NixOS/nixpkgs/blob/master/maintainers/maintainer-list.nix#L7), could you clarify the intended usage of the maintainer fields? @RaitoBezarius basically asks me to stop doing PRs, even though I usually get rather positive feedback regarding my contributions. This seems to be rooted in the maintainer record data scheme. Personally, I saw the status quo as being very reasonable as it leaves maintainers with a high level of control over their personal data, which seems to be important if we want to leave the door open to contributors from different jurisdictions. |
|
Just to be clear, I am not asking to stop sending PRs, I am asking that if a reasonable github field is available, that it is filled. As I am not able to find in the commit history the merge commit of your introduction as a maintainer (improper squash and merge?), I am not even able to read the prior discussion on the matter. Either case, not having your GitHub when it clearly exist makes any automation relying on this field impossible to build. We can conclude that we should leave this field optional but I cannot make any promise that any automation will take into account the special case that you are in all of nixpkgs, hence, why I recommended to consider stepping out of maintenance. I don't like GitHub either but this is the collaboration platform, if you don't want to participate socially in this, this will make everyone's life harder every time we need to reach you out. I am not in favor of that. |
|
I only made email optional; GitHub was and still is optional. Your information shouldn't have been included without at least telling you. |
|
And @tomkoid. |
|
Well, to me "contributing by sending patches via email" appeared to be synonymous to "not doing PRs" directly. But even if the whole thing appeared rather rude at first sight (personal data record being changed without prior notice, let alon consent, threat to make the fields mandatory), I do see your point and I'm glad to be able to discuss this in a less polarized manner. In case it matters, I looked up the conversation regarding my inclusion in the file: #259915 (comment) . Not sure whether I wrongly squashed or merged something back then. My point is: Yes, this is the collaboration platform currently, but whether it remains that way should depend on what the contributors want. I actually considered the whole Nix/NixOS/Nixpkgs ecosystem to be a rather promising example of how to at least minimize vendor lockin issues: E.g., we have automation that can notify between Discourse and GitHub, which is one step towards being able to contribute without being a GitHub customer (BTW, why is there no Discourse handle field in I understand that some automation might still work sub-par without allowing GitHub to be used and still decided to contribute, and I'll also be glad to offer maintainership for more packages I grasp well. In my experience, people were and are able to reach me, and if I see how to make it easier without consenting to data processing I don't like, I'll gladly do so. |
I agree and I apologize sincerely for this, this is my bad. |
Sorry for the tension, I felt also quite threatened by the GDPR argument which felt to me quite orthogonal as it didn't appear to me that your profile was PII per se. Nonetheless, putting this aside. I have suggested multiple times to work on independence efforts but all of that takes time, I think I do my fair share of that. Nevertheless, we only have finite time and energy. I don't want to get my energy drained in endless discussions on the ideal move to a better platform, especially when it's only discussions, I do prefer actions. Either case, I am working on pinging maintainers of security concerns and for this, the authentication has to go through GitHub (we don't have another silo of users, no LDAP, nothing.), I cannot really do anything about it, we don't have another ecosystem to authenticate people and maintainer-list is the only anchor for the permissions, in the absence of a link, I will simply not offer authentication to those users on the platform and disable all potential security notifications. I was under the hypothesis that this would be too much of a deal breaker compared to adding a GitHub handle which can be clearly found inside the commit history and for which I believed was just an overlook as I was not able to pinpoint the original PR. Anyhow, I present my sincere apologies to you and potentially @tomkoid who may also disagree on this addition. |
Well, happy to help on that. We don't need yet another promising OS to slowly stagger towards proprietaryness. |
This reverts commit 3429e79. GitHub names/ids are not mandatory for now. See #273220, #272199 and #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 #273220, #272199 and #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.
FWIW, this was added for a very different reason than what you're arguing here: f13283c |
I'm aware of that. Still, it's misleading to claim doing something to comply with the GDPR when the very same file is maintained under outright denial of the GDPR. |
Description of changes
This fixes various data integrity violations of reasonable expected schemes in nixpkgs.
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.