| 29 May 2023 |
 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 |
| infinisil | In reply to @infinisil:matrix.org
Otherwise I'm actually really liking pkgs/top now.. (top-level existing ruins it though) | 13:15:23 |
| @piegames:matrix.org | In reply to @infinisil:matrix.org
(top-level existing ruins it though) Let's keep that in mind for the day where top-level is renamed/removed then | 13:15:55 |
| infinisil | piegames: Oh I'd actually say that it's weird that when you import nixpkgs {}, that the result points at ./pkgs. Arguably the top-level attribute should be defined outside ./pkgs | 13:16:44 |
| infinisil | nixos and lib are somewhat ignored and need to rely on people importing them directly (or indirectly through pkgs.lib and pkgs.nixos) | 13:17:31 |
| infinisil | I'd be interested in more cleanly separating the top-level nixpkgs attribute into e.g. import nixpkgs {} == { pkgs = { ... }; lib = { ... }; nixos = ...; } | 13:18:09 |
| @piegames:matrix.org | In reply to @infinisil:matrix.org
piegames: Oh I'd actually say that it's weird that when you import nixpkgs {}, that the result points at ./pkgs. Arguably the top-level attribute should be defined outside ./pkgs Wait is this true? | 13:18:19 |
| @piegames:matrix.org | Ah nvm I misunderstood | 13:18:41 |
