| 18 Aug 2025 |
 raitobezarius | (again: it was not urgently wanted but this was my Morning routine™ of merging things that are lingering) | 15:34:22 |
 emily | I expect to get back to building my system closure ~today-ish | 15:34:25 |
| raitobezarius | alright, thanks! | 15:34:45 |
| raitobezarius | will prioritize the last pieces | 15:34:51 |
| emily | (FWIW I think "committers always merge" or "authors always merge" is probably a better norm than it depending, for the usual Gerrit reasons of "it's obvious whose turn it is" + knowing expectations for how you should communicate if some work is pending on some testing to obtain full confidence or such) | 15:35:59 |
| emily | (though for stuff like urgent fixes or security stuff the latter can be a pain I guess) | 15:36:14 |
| emily | Nixpkgs has some problems with this too. (where two parties in a PR will deadlock waiting for the other to hit the button) | 15:36:33 |
| raitobezarius | (I'd also prefer that but the merge queue situation means that I have more people demanding why something is not merged than anything and teaching everyone about Gerrit's etiquette takes a lot of energy) | 15:36:39 |
| raitobezarius | (so I have a more complicated hybrid strategy where I do take care of things and do merge things) | 15:36:50 |
| emily | merge queues would be very nice | 15:36:55 |
| emily | having two stacks that you have to babysit the rebase ordering of to get the tests happy to merge is tedious | 15:37:10 |
| emily | does the Snix thing for that not work well? | 15:37:16 |
| raitobezarius | It has bugs and it would take much more energy to take care of these bugs or cleanup after a massive disaster in production | 15:37:36 |
| raitobezarius | So until I have a window of opportunity for removing this painpoint, manual and tedious is fine as I have a bird view of everything and I know my way through all the ecosystem easily | 15:38:27 |
| raitobezarius | The only problem are well, these situations :) | 15:38:32 |
| raitobezarius | * The only problems are well, these situations :) | 15:38:35 |
| raitobezarius | In reply to @raitobezarius:matrix.org
It has bugs and it would take much more energy to take care of these bugs or cleanup after a massive disaster in production (which are not a virtual problem, they happened.) | 15:40:38 |
| raitobezarius | emily i verified what i wanted on cl/3852 | 15:43:19 |
| raitobezarius | emily also consider abandoning the alternative path at this point | 15:43:47 |
| raitobezarius | it confuse me always when i encounter while looking at the relation chain | 15:43:56 |
| raitobezarius | (we can always un-abandon it if needed) | 15:44:02 |
| emily | 3869 you mean? can do when I get back to the stack. possibly later today. still have some thoughts I need to post about 3870 (but I've been running it and it's been fine) | 15:56:01 |
| emily | need to get the reproducibility stuff sent out to Nixpkgs but hopefully I will get to that part of the backlog today | 15:56:30 |
| raitobezarius | dw | 17:47:03 |
| raitobezarius | emily does https://git.lix.systems/lix-project/lix/issues/966#issue-14037 ring a bell to you? | 22:34:58 |
| raitobezarius | sounds like something related to the range we just merged | 22:35:06 |
| raitobezarius | it's a no sandboxing case so… | 22:35:12 |
| raitobezarius | actually, the range is larger | 22:35:48 |
| emily | what's the tests right after the ones reported | 22:41:55 |
| emily | the flake ones are really slow but I guess not hours slow | 22:42:04 |
