| 27 Sep 2023 |
 @piegames:matrix.org | In reply to @infinisil:matrix.org
I really think most people do agree with how it's going. I don't think there was a single person arguing for keeping the directory structure throughout the RFC Yep, the discussion skipped the contents of the RFC entirely and directly jumped to the bike shedding part ^^ | 10:16:15 |
 @syphoxy:matrix.org | RFC 146 is really promising and I hope it goes through as quickly as RFC 140 did. | 14:17:09 |
| @piegames:matrix.org | I'm not optimistic about that. 140 enjoyed a wide community consensus which is otherwise pretty rare | 15:26:47 |
 infinisil | I'm tending towards accepting 146, it's not bad. However I also think it's a distraction from other problems that would be more important to fix | 17:24:12 |
| infinisil | Losing the categorisation seems very minor in comparison | 17:28:02 |
| infinisil | Unrelated to that, an observation relating to PR CI checks in general: Aren't they kind of flawed? Because the main branch continuously updates, but the CI checks for each PR aren't re-run | 17:32:53 |
 K900 | They are | 17:33:07 |
| K900 | Ideally we'd have bors | 17:33:11 |
| K900 | But it's hard | 17:33:28 |
| @piegames:matrix.org | And is it worth the effort? | 17:33:44 |
| infinisil | I guess merge trains would improve on that | 17:33:45 |
| K900 | In reply to@piegames:matrix.org
And is it worth the effort? I think it's worth considering in the general effort to fix our CI situation | 17:34:14 |
| K900 | Is it worth doing by itself? Probably not | 17:34:24 |
| K900 | Is it worth doing as part of a bigger project to replace hydra/ofborg/etc? Absolutely yes | 17:34:49 |
| infinisil | piegames: On the scale of Nixpkgs it might be, because we have so many PR's, many of which linger around for a while | 17:34:53 |
| infinisil | Any CI checks that newly fail would then break on master when those PR's are merged | 17:35:11 |
| infinisil | In particular I'm thinking of https://github.com/NixOS/nixpkgs/pull/211832#issuecomment-1732153092 here | 17:35:54 |
| @piegames:matrix.org | Btw this has a hard dependency of going through a merge bot for everything | 17:36:14 |
| infinisil | The first step should be to disallow definitions in all-packages.nix when they should be in pkgs/by-name instead. But if we just put that in a CI check, it would fail regularly for probably some days as people merge all-packages.nix changes in | 17:36:48 |
| K900 | In reply to@piegames:matrix.org
Btw this has a hard dependency of going through a merge bot for everything Not necessarily | 17:36:57 |
| K900 | But I also don't think this is too bad, generally | 17:37:13 |
| @piegames:matrix.org | Oh I absolutely do want a merge bot, and soon pretty please | 17:37:49 |
| infinisil | The idea given here should help for some cases: https://github.com/NixOS/nixpkgs/issues/256788 | 17:38:34 |
| infinisil | I'll probably go for that regarding RFC 140 | 17:38:41 |
| infinisil | In short: Run both the old and new CI checks, on both the base and merged state, then figure out when it makes sense to fail the check based on that | 17:39:33 |
| @piegames:matrix.org | Why so complicated? GitHub actions already always run on the merged code (IIRC), so simply pin the version in the repo and you're done? | 17:40:54 |
| infinisil | piegames: Because the CI check might be outdated | 17:41:32 |
| infinisil | CI check runs successfully, master branch updates with stricter checks, PR gets merged, master is broken | 17:41:50 |
| infinisil | With a strategy as described, you can kind of guarantee that any new PRs won't break master if merged | 17:43:29 |
| @piegames:matrix.org | Ah. Yeah, merge bot. Or have a bot that forces a rebase after any CI changes | 17:43:46 |
