| 26 Feb 2024 |
 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 |
| infinisil | Oh yeah that sounds nice | 17:35:02 |
| Philip Taron (UTC-8) | But since we're in "default GitHub" world, we must make do. | 17:35:05 |
| Philip Taron (UTC-8) | It's OK. | 17:35:07 |
| infinisil | Gotta work with the tools you have! | 17:35:47 |
| infinisil | (up to a point!) | 17:35:52 |
| Philip Taron (UTC-8) | In reply to @infinisil:matrix.org
Gotta work with the tools you have! Did the work, PR reviewed. Biggest blocker is the non-reproducibility of the tests since they encode /home/tweagysil/src, then lots of English wordings and suggestions. | 21:04:11 |
| 29 Feb 2024 |
|  @adam:robins.wtf joined the room. | 03:22:59 |
|  @2xsaiko:tchncs.de joined the room. | 03:23:03 |
|  @nscnt:matrix.org joined the room. | 07:07:56 |
|  Jonas Chevalier joined the room. | 14:56:35 |
| 1 Mar 2024 |
|  tomberek set a profile picture. | 15:20:36 |
| 2 Mar 2024 |
|  @dooy:matrix.org left the room. | 11:27:53 |
|  Qyriad joined the room. | 19:34:26 |
| 5 Mar 2024 |
| infinisil | @room Meeting now (meeting link, meeting notes. We didn't really reach consensus last time, but I do finally think that we can call this the final meeting. | 14:00:40 |
 nbp | Robert Hensing (roberth): Thanks for opening #273815 , what you suggest about using the update operator (//) reminds me of an old proposal named S.O.S. ;) | 14:19:00 |
| tomberek | I'm not available this week. | 14:19:44 |
| nbp | I think the mkDerivation application (calling with it) should be moved out of the fix-point if we want to keep use the update operator or any derivative of it. | 14:19:52 |
| nbp | Thus one would set builder = stdenv.mkDerivation; recipe = { /* mkDerivation argument */ }; and a final phase will go after the fix-point to apply the builder to it argument. | 14:21:20 |
| nbp | The same can be considered for migrating callPackage / mkScope resolution. | 14:22:08 |
|  Dominic Mills joined the room. | 14:22:19 |
| nbp | but we might need an update operator which works across functions, which it currently does not. | 14:22:33 |
 cab404 | hmm, still can't add https://calendar.google.com/calendar/u/0/embed?src=b9o52fobqjak8oq8lfkhg3t0qg@group.calendar.google.com&ctz=Europe/Zurich as a calendar | 15:06:24 |
| cab404 | Ohh, found it https://calendar.google.com/calendar/ical/b9o52fobqjak8oq8lfkhg3t0qg%40group.calendar.google.com/public/basic.ics | 15:09:31 |
 Robert Hensing (roberth) | In reply to @nbp:mozilla.org
Thus one would set builder = stdenv.mkDerivation; recipe = { /* mkDerivation argument */ }; and a final phase will go after the fix-point to apply the builder to it argument. Where builder and recipe are attributes of the overridable fixpoint, I suppose?
With something like lib.encapsulate, that would be
lib.encapsulate (this: {
builder = stdenv.mkDerivation;
recipe = { name = "hello"; ..... };
public = this.builder this.recipe;
})
| 16:41:02 |
