| 29 May 2023 |
 infinisil | I think this is being blown out of proportion | 11:46:42 |
| infinisil | We're talking about situations where: The standard needs a small uncontroversial change, the NAT team does not exist anymore, there's enforced protection of changes to the standard | 11:47:57 |
 Alyssa Ross | RFCs are difficult to change later, so it's really important to get what goes into them right | 11:48:18 |
| infinisil | If the standard is controversial -> RFC; if the NAT does still exist -> just wait for approval; if there's no enforced protection -> just change the files, if the NAT doesn't exist anymore, nobody would complain | 11:48:58 |
| infinisil | And if all three are the case, talk to a NixOS org admin to remove the restriction | 11:49:56 |
| Alyssa Ross | oh I think we might be at crossed wires here | 11:50:08 |
| Alyssa Ross | piegames said "if you really want to then put that into the RFC" | 11:50:22 |
| Alyssa Ross | but I now notice you didn't actually mention putting this in the RFC | 11:50:30 |
| infinisil | In reply to @infinisil:matrix.org
Hmm, how about "This RFC describes the initial standard. The up-to-date standard will be in the Nixpkgs manual. Smaller changes to the standard may be performed by the Nixpkgs Architecture Team without an RFC, while larger changes will need another RFC" Alyssa Ross: This here | 11:50:50 |
| Alyssa Ross | Would "Smaller changes to the standard may be performed without an RFC" work for you? | 11:52:10 |
 @piegames:matrix.org | I'm struggling to imagine any changes that are "minor" in scope yet would be controversial enough to warrant a discussion with the NAT | 11:52:37 |
| infinisil | I think changes being uncontroversial means that the NAT will accept them, and them being uncontroversial the opposite | 11:53:19 |
| @piegames:matrix.org | Okay, then I'm struggling to imagine a minor but controversial change in this context | 11:53:53 |
| infinisil | Yeah that wouldn't exist then, any minor change would be accepted by the NAT | 11:54:18 |
| infinisil | In reply to @qyliss:fairydust.space
Would "Smaller changes to the standard may be performed without an RFC" work for you? So I think this wouldn't work for me, because I don't necessarily trust the ~200 committers of nixpkgs to be able to decide what a smaller/uncontroversial change to the standard is | 11:54:51 |
| 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 |
