| 29 May 2023 |
 infinisil | I did call out people merging their own stuff though, which is a similar problem | 12:29:01 |
 raitobezarius | What you're raising here is committers that contributes a change they don't fully understand would get confidence on doing more changes and may pull off a mistake someday ? | 12:29:05 |
| raitobezarius | In reply to @infinisil:matrix.org
I did call out people merging their own stuff though, which is a similar problem I agree this is IMHO a big problem but out of scope for this discussion | 12:29:20 |
| infinisil | In reply to @raitobezarius:matrix.org
What you're raising here is committers that contributes a change they don't fully understand would get confidence on doing more changes and may pull off a mistake someday ? Committers that merge somebody else's contribution, either of which may make a mistake due to unfamiliarity with the code | 12:29:59 |
| raitobezarius | I feel like this is an extremely general and prevalent problem in nixpkgs, one of which I made the mistake of doing also | 12:30:49 |
| 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 |
| infinisil | Oh yeah it was mentioned here: https://github.com/NixOS/rfcs/pull/140#issuecomment-1565609228 | 13:02:28 |
| @piegames:matrix.org | In reply to @infinisil:matrix.org
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 I wouldn't say "better", but "acceptable". I'm not against looking for a good name that actually relates to its concept | 13:07:04 |
| @piegames:matrix.org | Some more hip shots: pkgs/packages, pkgs/main | 13:07:28 |
| infinisil | Immediate thoughts: pkgs/packages -> it's weird to have the same thing twice in a row, what should go into pkgs but not pkgs/packages? If it's a package it should definitely go into pkgs, but then why not pkgs/packages because that also means packages | 13:10:02 |
| infinisil | pkgs/main feels like it's the main packages, who decides which packages are the main ones? Or alternatively it looks like an entry-point, but it's not where the entry-point is. | 13:11:17 |
| infinisil | piegames: What about pkgs/top? | 13:11:37 |
| @piegames:matrix.org | In reply to @infinisil:matrix.org
piegames: What about pkgs/top? IMO that's even more confusable with "top-level" than "main" | 13:13:08 |
| infinisil | The one problem there is that while only top-level packages are included in the standard, it's not all top-level packages. In particular only packages defined using callPackage are included, but we can imagine wanting those to be included in the future once we figure out a better specification for package declarations | 13:13:18 |
| infinisil | piegames: Ah true, though I'd argue that top-level should eventually be renamed to e.g. package-sets or so | 13:14:29 |
| infinisil | Otherwise I'm actually really liking pkgs/top now.. | 13:14:50 |
| @piegames:matrix.org | For folder names, there's always some ambiguity to how to interpret their name. Is "top-level" the place to put all top-level packages, or where the top-level is defined? Is "main" the entry point of the code, or the main place to put packages? | 13:15:15 |
