zfsUnstable: 2.1.12 -> 2.2.0-rc2

[numinit]

Description of changes

New ZFS release candidate compatible up to Linux 6.4 supporting things like block cloning and SIMD SHA-2 implementations.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 23.11 Release Notes (or backporting 23.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

[RaitoBezarius]

Too many people depend on zfs unstable for the latest kernel, 2.2.0-rc2 is excessively dangerous IMHO, we should wait until 2.2.0 is really released.

[RaitoBezarius]

We could bump unstable to 2.1.13 instead if you want.

[numinit]

Hmmm. I see the risk. Perhaps we ought to have a zfsBleedingEdge that's gated behind a "you'd better know what you're doing" flag somewhere.

OTOH, more maintenance, so I'm happy leaving this be for now until 2.2 actually is released.

[RaitoBezarius]

Yeah, I believe it's better to leave this open until 2.2.0 is out and often NixOS contributors tested it by applying this patch locally.

[numinit]

Flagging as draft so we can revisit when 2.2 is out for real.

[GGG-KILLER]

I don't think getting an rc is risky considering that zfsUnstable used to point to the staging branch commits which don't even have a proper release.

As a zfsUnstable user I'd rather have this point to 2.2.0-rc.3 so that I can securely use it with a 6.4 kernel than have it be a stable version even when it explicitly says unstable in its name.

[RaitoBezarius]

I don't think getting an rc is risky considering that zfsUnstable used to point to the staging branch commits which don't even have a proper release.

Staging branch receive(s|d) a different treatment regarding their testing scenario.

As a zfsUnstable user I'd rather have this point to 2.2.0-rc.3 so that I can securely use it with a 6.4 kernel than have it be a stable version even when it explicitly says unstable in its name.

That's not how zfsUnstable was built and used in the past.

[GGG-KILLER]

I remember often seeing zfsUnstable pointing to -staging branches' commit in the past.

But after searching for a bit I realized -staging branches come after the -release ones, so in this case it makes sense to keep in 2.1.x, I apologize for the confusion.

[RaitoBezarius]

Superseded by #246163, we will probably merge #246300 first for now. Please reopen if you think I missed something.