Remove impractical statement about backports #9188
Conversation
It has never been our policy to do backports for all intermediate versions. It goes against a rapid release scheme: if we release every few weeks, it's impractical to have to do backports against a gazillion releases between the latest stable version used by NixOS and the current Nix release.
|
I think it'd be great if there was tighter collaboration with the NixOS maintenance teams on this, too. For example, setting up an agreed schedule to migrate new Nix releases available on nixpkgs's master branch into the One "trap" in this current system is there's no real commitment or agreement about how long these versions are "supported" and people are accidentally bound on both sides of this. It'd be great to increase communication and reduce the friction here. For clarity, Nixpkgs master has the following releases:
while NixOS 23.05 has:
This is a lot of backports to make. Why do so many versions sntick around for so long? How do we reduce the number of versions that are considered "stable", and get focused on moving forward with quality and robustness? |
|
|
For each of those it seems to me that depending using Nix as a flake would better serve most of those options, including the cache -- since the cached versions are already prebuilt in c.n.o for releases. It doesn't seem to me that having them be available in the tip of nixpkgs (master/stable) is necessary to tick those boxes? |
|
I agree with @roberth: the reason Nixpkgs maintainers have to rely on multiple Nix releases is likely lacking quality assurance on our end. While we sure are liable to fixing that, I suggest to defer the issue of how to deal with that reality within Nixpkgs and NixOS to Nixpkgs and NixOS maintainers, as it won't change quickly. Improving the testing situation and stabilising programmable interfaces are two of our too many priorities. In my opinion these should be the only ones until further notice. Both are expensive and unappealing, therefore neither likely to get done by volunteers nor easy to get funding for. |
|
We’re taking it as a given people are depending on versions like 2.15, 2.14, etc… but I sort of doubt it. Can we add data to the discussion to help guide the versions that are considered relevant? Some folks will use them just because they’re there, but again: we don’t need to keep arbitrary versions in the current nixpkgs for unclear reasons. Just like we don’t keep a zillion versions of other tools in nixpkgs.
…On Thu, Oct 19, 2023, at 8:44 PM, Valentin Gagarin wrote:
I agree with @roberth <https://github.com/roberth>: the reason Nixpkgs maintainers have to rely on multiple Nix releases is likely lacking quality assurance on our end.
While we sure are liable to fixing that, I suggest to defer the issue of how to deal with that reality within Nixpkgs and NixOS to Nixpkgs and NixOS maintainers, as it won't change quickly.
Improving the testing situation and stabilising programmable interfaces are two of our too many priorities. In my opinion these should be the only ones until further notice. Both are expensive and unappealing, therefore neither likely to get done by volunteers nor easy to get funding for.
—
Reply to this email directly, view it on GitHub <#9188 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAASXLCP5TT7CFMPXAKN4ETYAHCPTAVCNFSM6AAAAAA6HM3QLCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZRHA4TMMZVGY>.
You are receiving this because you commented.Message ID: ***@***.***>
|
|
I asked during the meeting, is making backports even hard? I think it takes about 1 minute per backport. @edolstra seems to say actually it's not the backporting that is hard, but the releasing afterwards that is. That makes a lot more sense, and IMO clarifies what we we should do --- make releasing easier. |
|
|
||
| Backports never skip releases. | ||
| If a feature is backported to version `x.y`, it must also be available in version `x.(y+1)`. | ||
| This ensures that upgrading from an older version with backports is still safe and no backported functionality will go missing. |
There was a problem hiding this comment.
If we end up keeping the current de facto situation that releases between the one used in NixOS and the latest won't have backported patches, we should at least state that explicitly here.
I still think it would be suboptimal, and things just working as one would expect would be way better UX than some random place in the manual saying "tough luck", but at least people will have a way to be sure about it.
|
Having done two series of backports today. The circumstances were pretty bad.
More observations:
Conclusion
|
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2023-10-20-nix-team-meeting-minutes-96/34557/1 |
|
Discussed in Nix team meeting:
|
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2023-11-10-nix-team-meeting-minutes-102/35379/1 |
I don't have a direct answer to that question, but I can point out a pattern of Nix versions being unstable on their initial release, which, when wearing my distro maintainer hat, I would say leads to desire to be very cautious with updating to newer releases without also testing them pretty extensively. Given this pattern plus the lack of C++ API compatibility across releases, I think that the current NixOS policy of maintaining the set of Nix versions that was there at release until the release goes EOL is pretty reasonable in view of keeping peoples' systems working on the versions they know work correctly. The reason I've noticed these breakages, incidentally, is because I get pinged with most Nix releases updating in nixpkgs due to the Nix C++ API changing (for a pretty simple use case) and causing a To illustrate, here is a likely-incomplete list of Nix versions that have had broken initial releases due to inadequate testing upstream in about the past year, which led to being reverted downstream in nixpkgs:
When a release breaks in such a way that downstream catches it, it creates a need for emergency releases of dependent projects such as nixpkgs or the installer to revert the updated Nix version, and it erodes trust in new releases being good enough to ship quickly. My suggestion to the Nix team is to work on making testing more extensive and to spend more compute on testing releases. It is worthwhile compiling a list of commonly used CI tools and adding them to tests. It is likely worthwhile writing some tooling to check code coverage on evaluating/building things from nixpkgs with hydra or similar, and hunt for tests that add coverage that is not hit in the Nix test suite. Operationally, #7830 regressed since apparently the tests weren't run(?). I suspect this process issue has been fixed since. I agree with the comments above about improving the release process rather than stopping doing backports. To be clear, Nix is not uniquely bad on this. However, without putting in the work to get a rate of regression closer to Rust's, for example, where there are |
Actually shortly after the NixOS release is another opportunity, because we get to backport the churn (if it's low risk!) at the lower cost of one or two releases worth of backports. |
|
Closing as we now implement the procedure as described. |
Motivation
It has never been our policy to do backports for all intermediate versions. It goes against a rapid release scheme: if we release every few weeks, it's impractical to have to do backports against a gazillion releases between the latest stable version used by NixOS and the current Nix release.
Context
Priorities
Add 👍 to pull requests you find important.