What should stable NixOS prioritize?

Development
81

Historically, it was hard because there would be several breaking changes introduced into staging right before branch-off. This caused a situation in which significant additional work was needed to make the broken packages usable again across divergent branches.

For the 20.09, the biggest blocker was the weird mix of plasma + qt + systemd, which caused a lot of issues. When 20.09 was finally cut, we had an EOL version of plasma which required bespoke patches to work in the release; while unstable had the latest and greatest which didn’t require any additional patching. DE schedules have been mitigated by pushing the release date until after the big gnome and plasma releases in RFC 80, so they will likely support our version of systemd and other assumptions which were made during development.

Further breakages are mitigated by RFC 85, in which breaking changes for packages which target staging need to be delayed until after the release. This is to prevent using staging-next cycles to fix something that broke right before release. Changes which target master can be iterated on master, which is much shorter (usually <24 hr) iterations; thus breaking to changes to master are always okay.

7 Likes
82

I think the RFC 85 is the really critical one to think about here. Even if we didn’t have releases, we could still have such a bi-annual “settlement” period were such big breaking changes are not allowed. “Settlement”, “sleep”, “duty cycles” are the operative analogues in this case, I think.

3 Likes
83

I actually though that doing a “mid-term” / mini-zhf would be good as well, just to keep failing builds lower. But that would be a fair amount of “work” work, and I didn’t want to burn anyone out.

I think the most sustainable process would be to have master contributions be as “routine” and quick as possible. The staging / staging-next workflow also needs some more testing rigidity to make a lot of breaking changes better as well.

2 Likes