| 31 Mar 2025 |
 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 |
| emily | and right now I am taking time out of my evening outside because the costs of insufficient communication have been externalized and this needs resolving days before the freeze | 20:58:34 |
| John Ericson | this is why it is crucial to mentally separate 2.2{4,7} from build system / packaging / etc. | 20:58:51 |
 ElvishJerricco | raitobezarius: I would like to know an example I could use to verify whether or not Nix actually has the problem you describe. | 20:58:54 |
| John Ericson | emily: I would just go back to doing your normal evening things then | 20:59:16 |
| emily | In reply to @Ericson2314:matrix.org
this is why it is crucial to mentally separate 2.2{4,7} from build system / packaging / etc. as I said, if the old packaging was restored then there would be a much more viable discussion of whether to bump | 20:59:38 |
| emily | I'm happy to separate those | 20:59:45 |
| John Ericson | let me try to do this bump, and if I screw it up in the next few days you can "haha told you it was harder than you thought!" me all you like :) | 20:59:52 |
| emily | i don't think "don't worry about it, I'm going to do it anyway" is reassuring for the concerns I am trying to raise | 21:00:19 |
