| 31 Mar 2025 |
 emily | i will comment again later once I am no longer on phone keyboard | 20:39:03 |
 ElvishJerricco | I think the fact that Nix is a core component of the OS is a good reason that it should be bumped. We want the default version to be one that's more actively maintained, which a newer version like 2.27 or 2.28 would be. | 20:40:42 |
| emily | it's not going to be the latest for long. the Nix team policy is supporting the latest version and the one in stable Nixpkgs | 20:43:19 |
 John Ericson | emily: I think we've done fairly little feature-behavior churn since 2.24 | 20:43:23 |
| emily | which is their decision of course but it shouldn't impact Nixpkgs release cycle decisions | 20:43:37 |
| John Ericson | like, because we've been busy with this stuff, the actual behavior Nix is relatively unchunged | 20:43:47 |
| John Ericson | so I would expect a good bit less behavior difference than e.g. that between 2.18 -> 2.24 | 20:44:17 |
| John Ericson | roberth's been dogfooding new Nix, and I plan to in a moment too | 20:44:53 |
 raitobezarius | didn't output path calculation change between 2.24 and 2.28 again? | 20:45:25 |
| emily | the only way we're going to avoid the 2.18 logjam repeating over and over is if the Nix team actually puts in the effort to communicate proactively with Nixpkgs processes and take the concerns seriously rather than throwing things over the wall last minute. as so often, it's about communication. Tom's comment claimed that 2.24 would remain the default only a few hours ago before being edited | 20:45:30 |
| emily | if this had been talked about earlier the concerns could have been raised and timing could have been discussed. when I tried to use the new packaging only weeks ago it wasn't in a state to even be nixVersions.latest | 20:46:17 |
| John Ericson | Nix in Nixpkgs would have already been bumped except for the packaging churn, so there is a bit of a tangled causality here | 20:46:19 |
 Robert Hensing (roberth) | not that I know of. Where would that be? | 20:46:59 |
| emily | that's your prioritization decision though... | 20:47:04 |
| emily | this is why upstream=downstream is fraught at the best of times. the incentives are just not the same | 20:47:26 |
| John Ericson | pre planet Nix I was really busy doing other stuff in Nix (and also win work, unrelated to Nix!). Now after words I stick my head up for air and see --- oh shit, new Nixpkgs is almost here, and we're really behind | 20:47:46 |
| John Ericson | I've put all the CA and dyn drv and other personal priorities on hold to get this stuff sorted | 20:48:02 |
| raitobezarius | In reply to @roberthensing:matrix.org
not that I know of. Where would that be? latest I have in mind is that output path calculation change with fetchTree and file:// between 2.19 and 2.24, I'd need to look again in my notes | 20:48:23 |
| John Ericson | get the headers, the package config, the nixpkgs legibility, and other things that need to get bumped sorted | 20:48:25 |
| raitobezarius | but I'd appreciate if this could be tested before Lix has to discover it :P | 20:48:40 |
| John Ericson | it's not the ideal timing for sure! No disagreement from me there! | 20:48:59 |
| John Ericson | raitobezarius: I recall some Lix patch that made it respect the fetching equivalent of outputHashMode | 20:49:21 |
| John Ericson | that sounds like something we should have | 20:49:26 |
| John Ericson | it didn't look like a regression | 20:49:37 |
| John Ericson | but respecting the thing does look more correct than not | 20:49:50 |
| raitobezarius | well, this was a bug that was fixed but caused output path calculation changes which goes against the contract of reproducibility | 20:50:10 |
| raitobezarius | this meant that who had in their cache had to cache bust everything | 20:50:21 |
| raitobezarius | * this meant that who had this in their cache had to cache bust everything | 20:50:27 |
| emily | there's a reason we ended up on 2.18 for so long and rushing while waving away concerns isn't going to fix it :( if we want to keep the versions synced then there needs to be work to rebuild the trust that concerns will be taken seriously and regressions handled. those concerns right now include timing relative to the freeze, breaking patches/flag overrides with zero deprecation period for one of the most critical packages,the packaging rewrite being understood by maybe 3 people in the world, and the fact that all this is being declared by fiat with no prior clarity | 20:50:33 |
| raitobezarius | the problem is not the bug the problem is that output path calculation changes are very visible especially if they do change a lot of paths | 20:50:46 |
