| 29 May 2023 |
 raitobezarius | Surely constraining might protect certain areas, but it doesn't address the root problem, does it? | 12:31:13 |
 infinisil | I think confidence to make more impactful changes is independent of having commit access to the parts that need to be changed | 12:31:47 |
| infinisil | raitobezarius: What is the root problem in your opinion? | 12:32:18 |
| raitobezarius | In reply to @infinisil:matrix.org
raitobezarius: What is the root problem in your opinion? I think it's actually multifactors:
- our "quick feedback" CI is suboptimal for many scenarios (nixos tests, etc.)
- we have an implicit principle of PR endorsement for committers in nixpkgs which grown out of "I don't want to merge this and get pointed out as the one who didn't test this enough" situation, related also to point (1)
- as a collective, we don't spend time coordinating nixpkgs wide policies by taking lessons of the past and edicting them to the community | 12:34:34 |
| raitobezarius | In reply to @infinisil:matrix.org
I think confidence to make more impactful changes is independent of having commit access to the parts that need to be changed I mean, it all depends on how you implement the restriction, if it's reserved only for your part, I'd say some people could feel distrusted and demotivated | 12:35:10 |
| raitobezarius | If it's for everyone as part of nixpkgs wide changes (ie a new RFC as Alyssa pointed), I'd actually think it could create interesting new dynamics | 12:35:47 |
| infinisil | In reply to @raitobezarius:matrix.org
I think it's actually multifactors:
- our "quick feedback" CI is suboptimal for many scenarios (nixos tests, etc.)
- we have an implicit principle of PR endorsement for committers in nixpkgs which grown out of "I don't want to merge this and get pointed out as the one who didn't test this enough" situation, related also to point (1)
- as a collective, we don't spend time coordinating nixpkgs wide policies by taking lessons of the past and edicting them to the community Yeah that sounds pretty good :) | 12:37:23 |
| infinisil | In reply to @raitobezarius:matrix.org
I mean, it all depends on how you implement the restriction, if it's reserved only for your part, I'd say some people could feel distrusted and demotivated I'd probably restrict it to something like "Active teams (for some definition of "active" and "team") are allowed to require their approval to code they own (for some definition of "own")" | 12:38:44 |
| infinisil | "Active" could be "have at least one open meeting every month where more than half of the team is present", "team" could be "at least 3 people", or something like that | 12:40:44 |
| infinisil | Maybe too synchronous, asynchronous should work too | 12:41:03 |
| infinisil | In reply to @raitobezarius:matrix.org
If it's for everyone as part of nixpkgs wide changes (ie a new RFC as Alyssa pointed), I'd actually think it could create interesting new dynamics How do you mean that? | 12:41:39 |
 @piegames:matrix.org | https://github.com/NixOS/rfcs/pull/140#discussion_r1209216688 opinions? | 12:53:28 |
| infinisil | piegames: Hmm, pkgs/default sounds like there's some Nix-builtin magic that defaults to that folder. Also instead of it being the default folder for packages it could also be interpreted as "this is where the default packages go", which then raises the question "which packages are part of the default ones?". Overall I'm meh on the idea | 12:57:52 |
| infinisil | I think it was also mentioned somewhere that a name that doesn't particularly mean anything is better because it makes it so people don't assume anything about it | 12:59:29 |
