nix: remove myself from "code ownership" and 2.3 maintenance

[RaitoBezarius]

Description of changes

I have no further plan to review CppNix code anymore, as I will dedicate myself to Lix development.
None of my machines are running CppNix anyway.

@flokli Godspeed on 2.3!

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• 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/)
• 24.11 Release Notes (or backporting 23.11 and 24.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.

---

Add a 👍 reaction to pull requests you find important.

[RaitoBezarius]

Paging the Nix maintenance team so they can find suitable replacements in the meantime.

cc @thufschmitt @fricklerhandwerk @roberth @Ericson2314 @edolstra @tomberek.

[Ma27]

Most people probably didn't even notice that I've also been codeowner/maintainer for a while, so less impact, but Given that I mostly run Lix these days, I don't think I can make calls suc as when it's appropriate to bump stable Nix.
That means, sooner or later I'll drop my maintainer status as well.

[fricklerhandwerk]

Is it documented somewhere what needs to be done to maintain the Nix package in Nixpkgs? I consider taking it.

[Ma27]

Not aware of this, but off the top of my head[1]:

• Keep Nix versions we've packaged up-to-date and apply security patches (and backport those!)
• Add new nix_X_Y attributes for new minors (and update latest attribute) and backport of appropriate
• Clean up unmaintained Nix minors.
• Keep nixVersions.git up-to-date[2] and backport.
• Decide which minor will be the next nixVersions.stable.
  • Special care must be exercised here given that 2.18 was kept for very good reasons so far. I recommend to have a few power-users (or be one yourself :p) to run a newer minor for a while for ~everything (means Hydra, home-manager etc) to see if there are notable regressions.

[1] feel free to document it somewhere, not having the time for this currently.
[2] This tracks Nix's master and is updated weekly. I usually run the lib tests against nixVersions.git as part of that procedure. Reasons are:

• catch issues related to our packaging as early as possible
• allow downstream users of Nix (e.g. home-manager, colmena or nix-darwin) to find issues on master with the way the use Nix without having to add another flake input just for that

[fricklerhandwerk]

@RaitoBezarius you listed your procedure for quality assurance here #315262 (comment)

• Build over all supported systems
• Build static binaries and test them
• Cross compile to classical supported systems
• Run i686, misc tests & all installer tests using that specific Nix
• Run library eval tests (normally, ofborg takes care of this for you, but double check it)
• Verify that nixos-enter behave as expected (a catastrophic regression for the stable Nix in general)
• Build Hydra with that Nix and verify it works out of the box
• Verify that the new Nix's fetchers work with things like npins, with some interesting cases, e.g. private forges, allRefs = true;, etc.
• Evaluate ALL of nixpkgs with nix-eval-jobs which tests two things: nix-eval-jobs compat and Nixpkgs evaluation ~correctness

I suppose you don't roll all of that by hand. Is there code to make all of that run with one command?

[Mic92]

• Evaluate ALL of nixpkgs with nix-eval-jobs which tests two things: nix-eval-jobs compat and Nixpkgs evaluation ~correctness

nix-eval-jobs has been pinned to a specific nix version for a long time. There is no need test this when upgrading the current default nix version. I already test this when releasing a new nix-eval-jobs version anyway.

[RaitoBezarius]

@RaitoBezarius you listed your procedure for quality assurance here #315262 (comment)

• Build over all supported systems
• Build static binaries and test them
• Cross compile to classical supported systems
• Run i686, misc tests & all installer tests using that specific Nix
• Run library eval tests (normally, ofborg takes care of this for you, but double check it)
• Verify that nixos-enter behave as expected (a catastrophic regression for the stable Nix in general)
• Build Hydra with that Nix and verify it works out of the box
• Verify that the new Nix's fetchers work with things like npins, with some interesting cases, e.g. private forges, allRefs = true;, etc.
• Evaluate ALL of nixpkgs with nix-eval-jobs which tests two things: nix-eval-jobs compat and Nixpkgs evaluation ~correctness

I suppose you don't roll all of that by hand. Is there code to make all of that run with one command?

I run this by hand mostly, I take care of bumps slowly over time, I never do all of that in one day or even in one week.

[RaitoBezarius]

• Evaluate ALL of nixpkgs with nix-eval-jobs which tests two things: nix-eval-jobs compat and Nixpkgs evaluation ~correctness

nix-eval-jobs has been pinned to a specific nix version for a long time. There is no need test this when upgrading the current default nix version. I already test this when releasing a new nix-eval-jobs version anyway.

Really the aim is to validate evaluation correctness, fixing nej compat is a secondary task of this task. I caught regressions in nej this way as well :P. Feel free to replace nej by the right instantiation of nix-env.

[Ma27]

nix-eval-jobs has been pinned to a specific nix version for a long time. There is no need test this when upgrading the current default nix version. I already test this when releasing a new nix-eval-jobs version anyway.

fwiw this is probably also about checking if any code in here causes issues with a new Nix.

Btw I'm sorry, I missed

@Ma27 are you still maintaining nix in nixpkgs or not?

in the other PR!

For now I'd say I'm out. PR will follow. Will revisit if Lix is released eventually and the packaging is shared[1].
Btw this means someone else needs to also take care of nixVersions.git.

[1] I heard rumors about Meson being merged downstream.

[fricklerhandwerk]

I consider taking it.

I don't think I'm equipped in terms of time, qualification, or hardware to take on such a responsibility (of which I already have more than enough).

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2024-06-03-nix-team-meeting-minutes-149/46582/1

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2024-06-05-nix-team-meeting-minutes-150/46583/1

[Artturin]

@Aleksanaa don't merge master to PR branches, it's clutter.

[Aleksanaa]

@Aleksanaa don't merge master to PR branches, it's clutter.

It's online conflict resolver. I forgot that.

Can I just squash-merge?

[flokli]

I think it's safer to fix this in the CLI.