| 5 Dec 2025 |
 leona | I wasn’t sure if the proposal is “give maintainers more time, reduce overlap support period” or “release earlier -> lengthen the support period” | 07:12:35 |
 vcunat | Down-sides of increasing overlap are there, too. For example, staging >>> master lag gets like doubled in that period. | 07:14:08 |
| leona | I personally think we should wait for a faster hydra, then the problems won’t matter this much | 07:15:22 |
 lennart | I'd propose I sent an email to nixpkgs core team summarising all your and mine input, and we'll figure out how to move forward with them? DM me your mail address if you want to be CC'ed. gonna write that mail next week. OK? | 07:19:49 |
| lennart | * I'd propose I send an email to nixpkgs core team summarising all your and mine input, and we'll figure out how to move forward with them? DM me your mail address if you want to be CC'ed. gonna write that mail next week. OK? | 07:20:59 |
| vcunat | Why not in public, e.g. discours? | 07:24:46 |
| lennart | was just thinking about that aswell, discourse is good. thanks you all! | 07:25:10 |
| lennart | will do that maybe today, surely by next week | 07:25:21 |
 emily | I'm not sure we have reason to believe this - NixOS on the desktop seems very/increasingly popular and we already tend to get GNOME/Plasma updates right in the very last stage of the release, would be rough to pull it back | 10:18:31 |
| lennart | yea, I agree that shifting to different months is not all too good. the solution suggested by vcunat is better (adding a few more weeks of support before EOL). | 10:19:38 |
| emily | fwiw the period where we support two stable releases simultaneously already feels pretty painful in terms of handling backports and balancing Hydra builds to me, but I guess a week wouldn't change that much (OTOH if it's because of holidays, many people won't be working on those things for that week anyway) | 10:19:43 |
| emily | (only a personal opinion, not speaking for any team) | 10:19:54 |
| lennart | all good, thanks for your input! | 10:20:04 |
| lennart | I have no rush about this, gonna write the discourse post, maybe do an RFC. and if it's better not to do that, fine. | 10:20:25 |
| lennart | * I have no rush about this, gonna write the discourse post, maybe do an RFC. and if it's better not to do that, fine. :) | 10:20:34 |
| emily | it may be worth considering switching during the final beta phase? | 10:20:46 |
| emily | although I run unstable so I would say that :) | 10:20:56 |
| vcunat | 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 |
