| 10 Dec 2023 |
 @joepie91:pixie.town | In reply to @julienmalka:matrix.org
Okay, sure, I don’t think that anyone is against having a discussion about the second point. The PR is merely saying: for that time that this situation is not changing and given that the metadata is here on the repo, let’s have it in a file that automation tools can parse. this is slightly moving the goalposts, though, and that is where much of the conflict comes from - "it is heavily dependent on github" and "you are required on github" are two different things. the former is generally agreed upon, but the latter is up in the air - yet the latter is what is being formalized by this policy | 20:45:38 |
 Julien | In reply to @joepie91:pixie.town
I actually just don't know yet whether it is reasonable to expect maintainers to maintain a github presence But what are the other ways currently to maintain a package ? Unfortunately the PRs/issues workflow is not compatible with not having a github presence. | 20:45:40 |
| @joepie91:pixie.town | In reply to @julienmalka:matrix.org
Okay, sure, I don’t think that anyone is against having a discussion about the second point. The PR is merely saying: for that time that this situation is not changing and given that the metadata is here on the repo, let’s have it in a file that automation tools can parse. * this is slightly moving the goalposts, though, and that is where much of the conflict comes from - "it is heavily dependent on github" and "you are required to be on github" are two different things. the former is generally agreed upon, but the latter is up in the air - yet the latter is what is being formalized by this policy | 20:45:43 |
| @joepie91:pixie.town | that difference is the source of the disagreement, AIUI | 20:45:56 |
 raitobezarius | In reply to @joepie91:pixie.town
this is slightly moving the goalposts, though, and that is where much of the conflict comes from - "it is heavily dependent on github" and "you are required to be on github" are two different things. the former is generally agreed upon, but the latter is up in the air - yet the latter is what is being formalized by this policy Well let me put it like this | 20:46:18 |
| raitobezarius | Currently, we have a maintainer list with no natural primary key | 20:46:26 |
| raitobezarius | Email, github, github ID, matrix are all optional and only one of them must be present | 20:46:41 |
| raitobezarius | Meaning you cannot order people according to one key (except the attributeset key) | 20:46:54 |
| raitobezarius | Right now, maintainers are not reconcilable, you cannot identify them at all and someone could duplicate themselves by adding an email, a matrix and a github all different in the maintainer list (absurd situation, I admit it) | 20:47:33 |
| raitobezarius | While it doesn't really matter for people consulting this list for doing things or ofborg which just ignores people with no github ID | 20:47:48 |
| raitobezarius | It matters to me to not build automation that will ignore people in the process and lock out people of the process | 20:48:00 |
 delroth | meta question: why is this being discussed on the #foundation channel when this has ~nothing to do with the nixos foundation? | 20:48:22 |
| raitobezarius | I spent some time thinking about alternatives but it seems irrealistic at the time to move the source of truth, that is, the permission bits and users in the NixOS GitHub organization in another silo of data | 20:48:27 |
| Julien | In reply to @joepie91:pixie.town
this is slightly moving the goalposts, though, and that is where much of the conflict comes from - "it is heavily dependent on github" and "you are required to be on github" are two different things. the former is generally agreed upon, but the latter is up in the air - yet the latter is what is being formalized by this policy I see what you mean. Personally I view it as « let’s write what is actually currently happening » but I did not realize people could see it as « let’s make github the only way to contribute as a rule ». For me it’s clear that if some people create alternative avenues for contributions that have sufficiently good properties for contributing with the other nixpkgs contributors, then we are going to remove that mandatory field, but maybe it is not clear to everyone. | 20:49:04 |
| @joepie91:pixie.town | delroth: the original point was regarding a policy change PR that was going outside of the RFC process, and then a meta conversation about the RFC process itself, it spiraled out of that | 20:49:06 |
| delroth | ok, but none of that has anything to do with the nixos foundation | 20:49:56 |
| @joepie91:pixie.town | In reply to @julienmalka:matrix.org
I see what you mean. Personally I view it as « let’s write what is actually currently happening » but I did not realize people could see it as « let’s make github the only way to contribute as a rule ». For me it’s clear that if some people create alternative avenues for contributions that have sufficiently good properties for contributing with the other nixpkgs contributors, then we are going to remove that mandatory field, but maybe it is not clear to everyone. but the problem is that "what is actually currently happening" is a subjective view, and that not everybody agrees on what that view is, and this change would declare one of those conflicting views as the source of truth. that is what makes it a policy change | 20:49:54 |
| delroth | rule of thumb: if it has nothing to do with administrative stuff (as in, legal entity), financials, trademarks, etc. - it has nothing to do with the foundation | 20:50:25 |
| delroth | (correct me if I'm wrong) | 20:50:32 |
| raitobezarius | we can move back this discussion to #dev:nixos.org but I agree there's kinda an unfortunate lack of avenue to discuss this | 20:50:48 |
| raitobezarius | maybe #team-members:nixos.org ? | 20:50:56 |
| delroth | github issue /s | 20:51:01 |
| raitobezarius | In reply to @delroth:delroth.net
rule of thumb: if it has nothing to do with administrative stuff (as in, legal entity), financials, trademarks, etc. - it has nothing to do with the foundation it's usually good to use the foundation channel to sort out meta level conflicts I suppose | 20:51:15 |
| raitobezarius | (though it should be unrelated) | 20:51:20 |
| @joepie91:pixie.town | In reply to @raitobezarius:matrix.org
I spent some time thinking about alternatives but it seems irrealistic at the time to move the source of truth, that is, the permission bits and users in the NixOS GitHub organization in another silo of data I find it difficult to build a full mental picture in an ad-hoc conversation like this, and aside from it not really being on-topic for this room, it seems like trying to discuss this in such an ad-hoc manner here is not going to be a good thing for the energy levels of anyone involved. this is why I suggested clarifying it fully in an RFC that describes the full rationale - it gives the space and time to evaluate the rationale, and address specific points in a system that's more conducive to this sort of discussion | 20:51:35 |
| @joepie91:pixie.town | In reply to @delroth:delroth.net
rule of thumb: if it has nothing to do with administrative stuff (as in, legal entity), financials, trademarks, etc. - it has nothing to do with the foundation I have been previously instructed to bring meta governance issues to here | 20:51:42 |
| @joepie91:pixie.town | if we have a better room, I'm happy to move there | 20:51:52 |
| Julien | In reply to @joepie91:pixie.town
but the problem is that "what is actually currently happening" is a subjective view, and that not everybody agrees on what that view is, and this change would declare one of those conflicting views as the source of truth. that is what makes it a policy change Correct me if I am wrong, but there is no other way to contribute to nixpkgs than to open a PR with your github account, which mean if it gets merged your github handle will be permanently written in the git history | 20:52:24 |
| raitobezarius | Let's move to #team-members:nixos.org | 20:52:40 |
 infinisil | In reply to @joepie91:pixie.town
cc infinisil re: the RFC stuff above If you scroll down a couple replies you'll see that I agreed with it being an RFC | 20:52:42 |
