| 10 Dec 2023 |
 Julien | Are you talking about:
- having people link their github handle on the maintainer-list.nix file
or
- nixpkgs contribution process being heavily dependent of having a github account ?
| 20:41:13 |
 @joepie91:pixie.town | I do agree that it can be difficult to draw the line. but I would argue that it's usually better to err on the side of an RFC; if nothing else, it will provide community practice for RFCs on relatively uncontroversial topics, you might uncover some concerns that you had not previously considered, and as the process matures, the "best case" for such RFCs is nearly indistinguishable in effort/speed from a regular PR (but you will end up with better historical documentation) | 20:42:00 |
| @joepie91:pixie.town | In reply to @julienmalka:matrix.org
Are you talking about:
- having people link their github handle on the maintainer-list.nix file
or
- nixpkgs contribution process being heavily dependent of having a github account ?
the latter; the former is an extension of that | 20:42:17 |
 raitobezarius | joepie91 🏳️🌈: how do you draw the line between nixpkgs contribution process and nixpkgs maintenance process? | 20:42:41 |
| raitobezarius | and how do you see the relation between GitHub being the place where we discuss code changes and many things with the maintenance process? | 20:43:02 |
| @joepie91:pixie.town | raitobezarius: I do not have enough information about the underlying considerations to draw that line; that is where I see value in an RFC that more clearly defines the rationale of how we got to this proposal, and what the considered alternatives were (and why exactly they were not viable) | 20:43:42 |
| @joepie91:pixie.town | * raitobezarius: I do not currently have enough information about the underlying considerations to draw that line; that is where I see value in an RFC that more clearly defines the rationale of how we got to this proposal, and what the considered alternatives were (and why exactly they were not viable) | 20:43:49 |
| @joepie91:pixie.town | I actually just don't know yet whether it is reasonable to expect maintainers to maintain a github presence | 20:44:21 |
| Julien | 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. | 20:44:30 |
| raitobezarius | 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 Right but not taking a stance on it will just let everyone working daily on nixpkgs take a stance for others | 20:44:57 |
| raitobezarius | What you are hinting at to me is something I have been meaning to do for a long time, that is, the maintainer RFC | 20:45:32 |
| raitobezarius | But I don't think current maintainers will appreciate it | 20:45:38 |
| @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 |
