| 5 Dec 2025 |
 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 |
| leona | and also it would need much more hydra capacity and also maintainer capacity to make staging cycles much less breaking | 10:46:04 |
| leona | also somehow find out how to not break users use cases too mcuh | 10:46:22 |
| leona | * also somehow find out how to not break users use cases too much | 10:46:23 |
 Vladimír Čunát | Well, some people pay for 10+ years of stable support in some distros... | 10:47:54 |
| Vladimír Čunát | Breaking changes are unavoidable and some people don't want to deal with them continuously. I can understand that. | 10:49:38 |
| emily | for many things having a defined process of adding a new version, ensuring everyone migrates to it, and then dropping the old one would be the same total work on Hydra but without breaking systems.
OTOH it's churn in terms of packaging/codebase and it fundamentally relies on expecting maintainers to be responsive
| 10:49:39 |
| emily | I don't think doing more jobsets would be that bad though, as long as the results can actually be triaged to maintainers. because after all we would be saving all the builds we spend on stable releases anyway | 10:50:29 |
| emily | but it all comes down to having responsive maintainers and the tooling to triage things to them IMO, otherwise we can't avoid breaking things for half a year and then scrambling for ZHF regardless 😅 | 10:51:48 |
| Vladimír Čunát | There are intentional incompatibilities, too. You have to do those at some points. (That's what I meant by "unavoidable".) | 10:53:19 |
| emily | right, hence ^. OTOH I do think that with better tooling we could achieve "6 months of deprecation before it breaks" for more things. | 11:03:55 |
| emily | (so you could still just let warnings pile up and solve them every n months, to some extent) | 11:04:13 |
| emily | question is how much work it'd be compared to maintaining a stable branch - and how many tooling improvements we'd need | 11:04:37 |
| emily | I hate dealing with compat and multiple versions, but if it was sufficiently streamlined and we had processes that reliably cleaned those up over time, it might be nicer than dealing with branches. | 11:05:39 |
| emily | (and even "safe" backports on stable branches do break people's deployments, sometimes) | 11:06:30 |
