| 5 Dec 2025 |
 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 |
 vcunat | Well, some people pay for 10+ years of stable support in some distros... | 10:47:54 |
| vcunat | 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 |
| vcunat | 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 |
| lennart | (gonna catchup on backlog soonish :} ) | 11:11:27 |
| lennart | ok caught up: could anyone reading this who has an opinion, please reply if a
👍️ if they think, I should follow through with a discourse post, to open up this discussion
👎️ if they think, the status quo is OK and works as intended
thanks! | 12:50:56 |
| lennart | * ok caught up: could anyone reading this who has an opinion, please react if a
👍️ if they think, I should follow through with a discourse post, to open up this discussion
👎️ if they think, the status quo is OK and works as intended
thanks! | 12:51:03 |
| lennart | * ok caught up: could anyone reading this who has an opinion, please react if a
👍️ if they think, I should follow through with a discourse post, to open up this discussion
👎️ if they think, the status quo is OK and works as intended (no post)
thanks! | 12:51:17 |
| lennart | I really am undecided and don't have enough insight into this topic | 12:51:50 |
| lennart | * ok caught up: could anyone reading this who has an opinion, please react if a
👍️ if they think, I should follow through with a discourse post, to open up this discussion
👎️ if they think, no further post is needed
thanks! | 12:53:39 |
