| 22 Mar 2023 |
 K900 | In reply to @whentze:matrix.org
it supports CODEOWNERS, that can do the trick as long as file granularity is good enough Then we'd have to have something maintain codeowners | 11:39:13 |
| K900 | Which is also iffy | 11:39:21 |
 raphi | will github complain if a non-committer is in CODEOWNERS? | 11:39:32 |
 Wanja Hentze | could we generate it from meta.maintainers? | 11:39:38 |
| *  @piegames:matrix.org would like to move to codeowners (or equivalent) by default anyways | 11:39:39 |
| K900 | In reply to@whentze:matrix.org
could we generate it from meta.maintainers? Possibly | 11:39:57 |
| K900 | But we'd have to build a tool for that | 11:40:05 |
| K900 | And then automate it somehow | 11:40:09 |
| Wanja Hentze | yes currently our CODEOWNERS mostly lists people with commit but but it should actually be the opposite imo | 11:40:12 |
| K900 | In reply to@raphi:tapesoftware.net
will github complain if a non-committer is in CODEOWNERS? Also good question | 11:40:23 |
 Alyssa Ross | CODEOWNERS only works for committers, no? | 11:40:25 |
| Wanja Hentze | if you have the commit bit you don't need CODEOWNERS anyway | 11:40:32 |
| K900 | But yeah basically the answer is "someone needs to write the damn thing and see what happens" | 11:40:38 |
| Alyssa Ross | it won't even let you add a team unless they're all committers | 11:40:38 |
| Wanja Hentze | oh damn | 11:40:55 |
| Alyssa Ross | yeah | 11:40:59 |
| Alyssa Ross | github makes some interesting decisions sometimes | 11:41:06 |
| @piegames:matrix.org | There are alternatives to CODEOWNERS written as GitHub action that suck less | 11:41:08 |
| Wanja Hentze | what the hell is it even for then | 11:41:13 |
| raphi | auto pining people in PRs | 11:41:22 |
| raphi | * auto pinging people in PRs | 11:41:27 |
| Alyssa Ross | well most repositories don't have "OWNERS" who can't commit | 11:41:36 |
| Wanja Hentze | we had a tool for that it was called ofborg | 11:41:39 |
| Alyssa Ross | we're a bit usunual | 11:41:41 |
 snowytrees | My thought is (I’m guessing ofborg) already knows to ping maintainers when a file is changed. So as long as changes are restricted to files under your purview you could merge. This would cover most cases of updates. If you change any files outside of it would need an actual committer? | 11:42:02 |
| Wanja Hentze | maybe you need to take into account more than just "what file in the repo changed" | 11:42:36 |
| Wanja Hentze | like "what output changed?" | 11:42:41 |
| @piegames:matrix.org | The problem is that we have meta.maintainers which is really fuzzy and also cannot be read without having to evaluate the entire nixpkgs first. IMO there is no way around moving this information outside of the nix code, and to make it per-file instead of per-package | 11:43:07 |
| Wanja Hentze | especially if you want to use this not just for packages but for NixOS modules (any module can do anything, mostly) | 11:43:11 |
| @piegames:matrix.org | * The problem is that we have meta.maintainers which is really fuzzy and also cannot be read without having to evaluate the entire nixpkgs first. IMO there is no way around moving this information outside of the nix code, and to make it per-file/folder instead of per-package | 11:43:12 |
