| 29 May 2023 |
 @piegames:matrix.org | In reply to @k900:0upti.me
Though I do think that having the ability to give people more granular permissions would be very nice This is not about removing everyone's general commit access. It's about being able to allow maintainers to merge changes their packages, without having to entrust them with the whole Nixpkgs repository | 12:15:42 |
 raitobezarius | In reply to @infinisil:matrix.org
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 But did we teach those committers this was not a good thing, etc. ? | 12:24:30 |
| raitobezarius | I mean before strengthening constraints, I'd love to read a clear motivation and rationale with data on how are we doing on this and what are the set of measures we can put forward to reduce those problems | 12:25:34 |
| raitobezarius | In reply to @infinisil:matrix.org
Same thing when people stop contributing, escalate to ones with more power. This is not my experience with how nixpkgs does things | 12:27:27 |
| raitobezarius | Usually when people goes AWOL it becomes unmaintained | 12:27:44 |
 infinisil | I haven't explicitly called it out, since in many cases I would've just merged it myself anyways, but I definitely questioned whether the committers actually understood the changes they just made, and whether they would be able to spot a mistake in such changes | 12:27:50 |
| 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 |
