| 18 Aug 2025 |
 emily | this stack includes the changes that make build directories always nondeterministic on Darwin, to be clear | 15:31:39 |
| emily | it looks like the diff I had locally for that part of the stack was only cosmetic. I have been running the entire stack for a long while now and it has not caused me problems, though I have not tested the prefix you merged very extensively and it still produces rather long build directories. I was hoping to resolve the remaining questions soon and waiting on your review for the nested directory stuff | 15:32:50 |
| emily | but it should be harmless given I didn't have significant unpushed changes and the code is good | 15:33:02 |
 raitobezarius | got it, still, I have to ask: is there any action you want to take regarding the merge? | 15:33:15 |
| emily | still some more communication would have been nice if it was urgently wanted, I was asleep for the two hours between ping and merge | 15:33:24 |
| raitobezarius | i.e. a revert or X or Y where X or Y can be 'let's do nothing for now' :P | 15:33:26 |
| raitobezarius | I apologize for the communication and from now on, I will communicate for your stacks | 15:33:39 |
| emily | I think let's do nothing and I will try to come back to the rest of the stack soon. but if you could finish reviewing the CL you have +1 on that would help | 15:33:48 |
| emily | since I assumed the work was blocked on that | 15:33:53 |
| 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 |
