| 20 Feb 2024 |
 szlend | Yeah, this is just me trying to follow whatever patterns are established by nixpkgs because I didn't feel like reinventing the wheel | 20:37:39 |
 K900 | It's not | 20:37:44 |
| K900 | Well it kinda is | 20:37:51 |
| K900 | But it's still a hack | 20:37:55 |
| K900 | I have ideas but that's a conversation for much later | 20:38:06 |
| 26 Feb 2024 |
 Philip Taron (UTC-8) | infinisil: I'm on deck to take a look through your by-name PR today. It's hefty! | 17:27:46 |
 infinisil | Philip Taron (UTC-8): Thanks and agreed! | 17:29:10 |
| Philip Taron (UTC-8) | At work, we use a approve-commits model, instead of an approve-PR model, which makes the review process substantially lighter. I'm sad that GitHub doesn't let that happen, since I only get the chance to review the whole squashed PRs. | 17:30:02 |
| Philip Taron (UTC-8) | * At work, we use a approve-commits model, instead of an approve-PR model, which makes the review process substantially lighter. I'm sad that GitHub doesn't let that happen, since I only get the chance to review the whole squashed PR. | 17:30:04 |
| infinisil | I should create smaller PRs than this really 😅 | 17:30:42 |
| infinisil | Though if I do small PRs in parallel, I'd get a ton of merge conflicts. And if I do them in series, it would take a long time to make any progress | 17:31:38 |
| infinisil | Some middle ground is probably best | 17:32:17 |
| Philip Taron (UTC-8) | Yeah; I think the PR size is OK iff the reviewer can say yes/no on each commit. | 17:33:56 |
| Philip Taron (UTC-8) | That powers you to make targeted fixes on each commit, which makes the merge conflicts lower, which enhances the whole PR, in my experience. | 17:34:41 |
