| 29 May 2023 |
Alyssa Ross | wouldn't CODEOWNERS etc and our existing social conventions be enough to enforce that? | 11:55:20 |
infinisil | Yeah probably, I guess it's somewhat implicit | 11:55:58 |
Alyssa Ross | like I'm not arguing the RFC should say "any committer is free to change how this works at any time" | 11:56:36 |
infinisil | If the NAT is a codeowner, I'll get notified, and if it's an uncontroversial change and I'm not on vacation I'll accept it | 11:56:58 |
Alyssa Ross | I'd expect people to wait for your input regardless of whether the RFC says they have to | 11:57:35 |
Alyssa Ross | and if they don't, well, then we probably have a problem that's wider than just auto-called packages | 11:58:02 |
infinisil | But then again, I don't think all of our 200 committers are aware of this RFC. It's easy to just randomly pick an RFC to review, decide that it looks trivial, and merge it | 11:58:31 |
Alyssa Ross | people are generally able to respect soft ownership without needing to know whether an RFC exists | 11:59:40 |
infinisil | I guess this should maybe go into a separate RFC then, to say that certain teams may take ownership with required approval over agreed-upon parts of Nixpkgs | 11:59:43 |
Alyssa Ross | or it could just… not, because this has not (to my knowledge) been a big problem with the current system | 12:00:27 |
@piegames:matrix.org | In reply to @infinisil:matrix.org I guess this should maybe go into a separate RFC then, to say that certain teams may take ownership with required approval over agreed-upon parts of Nixpkgs Yes, had this thought earlier on. I agree with your distrust towards the general commiters to some extent, but I'm not sure working around that in individual RFCs is the best approach.
This also ties in to the idea that we want a merge bot with a lot more granular access control to the repository …
| 12:01:05 |
Alyssa Ross | mostly if I ever see changes merged to areas of Nixpkgs that have a clear set of most-knowledgeable people without their approval, it's because somebody has been trying to get their attention for months and hasn't been able to | 12:01:17 |
infinisil | Hmm.. I've certainly seen certain committers merge changes to core parts of the code that they didn't really know much about, treating it like any other random package update | 12:01:20 |
Alyssa Ross | and if a bad change happens, we can revert it | 12:01:35 |
Alyssa Ross | (I do think we should be less scared of reverts than we currently are) | 12:01:43 |
infinisil | I'd be much more at ease if we could give more fine-grained permission over nixpkgs | 12:02:18 |
Alyssa Ross | that would be nice, yeah | 12:02:37 |
Alyssa Ross | although it's a balancing act | 12:02:59 |
Alyssa Ross | because at least for the work I do, I'm jumping about all over the place | 12:03:43 |
Alyssa Ross | but I think there are other committers who're more focused on specific areas, maybe? | 12:04:02 |
infinisil | Maybe cleaning up Nixpkgs to separate parts more cleanly ties into this | 12:04:15 |
infinisil | E.g. the whole idea of separating code into "units", so that the package definition and the NIxOS module are together, would make it easier to give somebody permission to change both at once | 12:04:50 |
Alyssa Ross | anyway I need to head out | 12:05:28 |
infinisil | Or moving the Python core infra into a single directory, instead of it being spread over pkgs/top-level/python-packages.nix, pkgs/interpreters/python and pkgs/python-modules | 12:05:28 |
infinisil | Nice discussion though, thanks for the feedback Alyssa Ross | 12:05:55 |
Alyssa Ross | yeah, thanks | 12:06:01 |
K900 | As someone who regularly makes small changes to random stuff, I would much prefer to not by granularly permission'd | 12:06:03 |
K900 | Though I do think that having the ability to give people more granular permissions would be very nice | 12:06:34 |
infinisil | I think with stronger nixpkgs teams, such that for every part of nixpkgs there's a timely response to proposed changes, this would work much better | 12:06:55 |
K900 | I mean | 12:07:05 |