| 5 Dec 2025 |
emily | although I run unstable so I would say that :) | 10:20:56 |
Vladimír Čunát | Well, you can start geting ready somewhere during the freezing for sure. | 10:21:36 |
lennart | what do you mean by that? | 10:21:53 |
lennart | aaaah got it | 10:21:59 |
lennart | yea… I am one (1) person for several systems… | 10:22:14 |
emily | you can roll out the new version just before release, or at least get ready and test it in advance | 10:22:25 |
lennart | employed by an NGO hussler life | 10:22:26 |
emily | last minute fixes right before release do happen, but they're usually not super critical things | 10:22:42 |
lennart | uhm, … gonna think about that. | 10:22:46 |
emily | you can just pretend the new release comes out a couple weeks earlier than it does, since it branches off like a month prior | 10:23:10 |
Alyssa Ross | even if you don't upgrade before release, you can at least have all the pre-upgrade work done by then | 10:23:23 |
emily | testing before the final release also helps surface issues to make our release go smoother :) | 10:23:54 |
lennart | that should be a solution to my problem, yes. I'll test with 26.05! | 10:24:10 |
emily | (otherwise they will often only be found after release) | 10:24:10 |
lennart | yea sure, but like … I'm working full time, and still cannot keep up right now. we are a smallish NGO, while I'm trying my best with my tasks :) | 10:24:52 |
lennart | lets not discuss that with this 300+ members channel. thanks a lot for all your input! :) gonna consider in the following days if/how I post in discourse. | 10:25:41 |
emily | (I wasn't trying to imply you should do anything that would be more work for you) | 10:26:52 |
lennart | all good, that's not what I understood by your words. just wanted to clarify | 10:27:24 |
emily | (just suggesting shifting back starting the migration to a new release by a week - since it should be basically the same but with more time to do everything. I'd expect that usually any major issues you run into this way would be present in the final release anyway :) ) | 10:28:02 |
lennart | yea sounds like a good solution to my specific problem :) just thought it should be that way more people are affected. but then again, there also is Ramadan, Diwali, Chinese New Year – not just Christmas to consider | 10:29:53 |
lennart | * yea sounds like a good solution to my specific problem :) just thought it should be ,that way more people are affected. but then again, there also is Ramadan, Diwali, Chinese New Year – not just Christmas to consider | 10:30:06 |
lennart | * yea sounds like a good solution to my specific problem :) just thought it should be, that way more people are affected. but then again, there also is Ramadan, Diwali, Chinese New Year – not just Christmas to consider | 10:30:10 |
emily | yeah, it would certainly be nice to give more time all else being equal | 10:34:53 |
emily | just feels tricky with the resources we have to do it meaningfully IMO | 10:35:12 |
emily | a couple extra weeks might not be so bad though | 10:35:22 |
Alyssa Ross | it would mean workload for nixpkgs maintainers peaks over Christmas, with two release branches to keep alive | 10:35:49 |
emily | people do say things like "ugh, let's just not bother backport, the release is going EOL in two weeks already" a fair bit already | 10:36:07 |
leona | Unfortunately (also because most contributors use unstable), the releases aren’t always appreciated by maintainers. Especially the period of 2 supported releases | 10:38:45 |
emily | in my ideal world we'd have processes allowing a rolling release to have as few regressions as our stable releases do now and the priceless RM work would be distributed over time as continuous quality improvement rather than batched up twice a year :) | 10:44:11 |
emily | (but this admittedly wouldn't solve the case where you really want to just put a config up and get security updates with 0 major changes for half a year - I guess the Cyberus LTS release type stuff would become more appealing for that kind of use case then.) | 10:45:08 |