| 31 Mar 2025 |
 emily | maybe all those concerns were resolved within the past few days? but even if so it would be premature to launch into a bump given that | 20:51:39 |
 John Ericson | I dunno what that editted thing was about because I woke up around 11 pm EDT | 20:51:43 |
| John Ericson | raitobezarius: I am not even arguing with you | 20:52:01 |
| emily | how can Nixpkgs and Nix communicate if y'all aren't even on the same page about packaging and defaults? | 20:52:04 |
| John Ericson | stop being slimy | 20:52:05 |
| John Ericson | lix has a fix, it ilooks good | 20:52:14 |
| John Ericson | we're happy to take it | 20:52:18 |
| John Ericson | the end | 20:52:19 |
| John Ericson | if there is a bug in the multitide of ways (too many!) fetchers can cash or not cash | 20:52:37 |
| John Ericson | it shuold be fixed | 20:52:41 |
 raitobezarius | sorry that you get that feeling, i am only repeating that it would be nice to mark output path changes as such and to verify those before sending a release | 20:52:48 |
| emily | I know it will cost you to postpone a bump until early on the next release cycle but you don't seem to fully appreciate the costs on our end, and offloading them to us will just give us 2.18 forever | 20:52:50 |
| John Ericson | I don't recall anyone touching that code recently, except for maybe eelco fixing a regression about whehter fetching should substitute | 20:53:09 |
| raitobezarius | fixing a crash does not always mean diverging the output path calculation | 20:53:17 |
| John Ericson | if it was a bug fix that caused a new issue, that's unfortuately (and a bit ironic) | 20:53:29 |
| John Ericson | but still goes to "no one has been tryign to do fancy new feature stuff here recently" | 20:53:46 |
| raitobezarius | but i feel like i'm derailing the important discussion emily is trying to have | 20:53:49 |
| raitobezarius | so let's leave it at it | 20:53:51 |
| John Ericson | ok, thank you. By all means, I don't want you all to have to bend backwards to be bug-for-bug compatible with us :) | 20:54:19 |
| John Ericson | so for any changes that looks unintentional, yes very good to let us know | 20:54:39 |
| John Ericson | we'll happy go back to older behavior that is unambiguously better | 20:55:00 |
| John Ericson | emily: I'm trying to offload no costs | 20:55:25 |
| John Ericson | I am saying I am personally gonna bare the burden of this as much as possible | 20:56:02 |
| John Ericson | until the new Nixpkgs is out | 20:56:05 |
| John Ericson | (and I will have some new on-the-job time for Nix things I can put towards this) | 20:56:27 |
| John Ericson | (as opposed to the less-good promise of after-hours time) | 20:56:44 |
| emily | that's ignoring the costs on the release process itself and externalizing the cost of things like there being no way to do overrides that works with both supported Nixpkgs versions and no deprecation period onto our users | 20:57:02 |
| emily | there's a reason we avoid doing major bumps shortly before release even when we haven't totally rewritten a package | 20:57:30 |
| John Ericson | I think that delay applies more to the source code / behavior content than the packaging itself | 20:58:12 |
| John Ericson | the thing that is rushed here feels much more "meta" | 20:58:21 |
