maintainers-list: create a field inactivityReason

[AndersonTorres]

Default null; should be a free-form string explaining why the maintainer
became inactive.

The most immediate use of this attribute is to mark maintainers that are
not contributing to Nixpkgs from a long amount of time. Nonetheless it can
be used to mark any long term inactivity, including but not limited to:

• Sabbatical leave
• Retirement
• Personal issues
• Force majeure

In principle, a third person can set this attribute. For the sake of a good
etiquette, in such case at least one contact attempt should be issued and
carried out before effectively committing it to the codebase.

This attribute can be employed to many useful activities, including but not
limited to:

• Treewide automation
  • Removal of inactive maintainers from packages
  • Orphaning alerts
• Filter automatic notifications

Description of changes

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.05 Release Notes (or backporting 23.05 and 23.11 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.

[K900]

Why?

[Aleksanaa]

In this way we can indeed trace other people's active status easily. But self mark as inactive and by others/bot have different meanings. If they are marked passively, they may not want to be disturbed, but this behavior may lead to more inactivity. It's good to use this to remind the maintainer or help remove inactive ones, but it also deserves more consideration.

[AndersonTorres]

Why?

Routinely I am bumping on code maintained by inactive people. #290642

Recently I am refactoring SDL and Guile libraries, and it is not hard to find people that are at least two years away from Nixpkgs.

It would be easier to have some help from Nixpkgs machinery to detect them.

---

If they are marked passively, they may not want to be disturbed, but this behavior may lead to more inactivity.

The idea is to mark cases of long term inactivity.
Also they are also free to return, just by updating the field.

It's good to use this to remind the maintainer or help remove inactive ones, but it also deserves more consideration.

Agreed.

[AndersonTorres]

Related issues:

• RFC 55 - Remove inactive Nixpkgs committers #88867
• [Tracking issue] Silent retirement of maintainers #290642

[nixos-discourse]

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

https://discourse.nixos.org/t/prs-ready-for-review/3032/4096

[SuperSandro2000]

The idea is to mark cases of long term inactivity.
Also they are also free to return, just by updating the field.

They would still receive PR review requests and the like. What would more align with the current tooling and not requiring further changes, would be to just drop those entries and maybe together packages they maintain which are broken for a longer time.

[AndersonTorres]

They would still receive PR review requests and the like.

The tooling can be updated to reflect this.

just drop those entries

I am accumulating days cleaning up SDL-related packages in a state of abandonment. This is being bureaucratic as hell.

[pbsds]

Aleksana said

But self mark as inactive and by others/bot have different meanings.

Rather than a boolean field, what if we make it nullOr str, where the string states the reason? Any string indicates inactivity. The field would also then need to be renamed.

[AndersonTorres]

Done. What do you think, @pbsds ?

[pbsds]

I like it! It could use an entry in the release notes, possibly some notes in the maintainer readme, and more opinions

[SuperSandro2000]

The tooling can be updated to reflect this.

But until that is done, this doesn't change things and from a reviewer perspective, this is completely intransparent. It would be way easier to review things, if the packages didn't have a maintainer, then we also wouldn't start a discussion with every PR that picks up an abandon package.

If we get that RFC thingy through for this and then once clean up inactive maintainers, we are done and don't need to adopt various tooling, add new labels to reflect that the supposed to be maintainer of a package is absent and probably more.

[AndersonTorres]

The tooling can be updated to reflect this.

But until that is done,

This is not the hardest thing on this planet.

this doesn't change things and from a reviewer perspective, this is completely intransparent.

Asking a dormant reviewer is not what I call transparency.

[pbsds]

This pr seems to be stuck in a limbo

• The [test] commit makes this un-mergeable as-is
• My request for some release note entry or documentation is unadressed
• We need more people to look at this and determine whether this is the direction we want to go or not since i don't consider myself influential enough to make that call. Should we advertise it on matrix?

[AndersonTorres]

This pr seems to be stuck in a limbo

* The `[test]` commit makes this un-mergeable as-is

It was a test and a proof of concept, I did it to catch errors.
I can delete it right now if you like.

* My [request for some release note entry or documentation](https://github.com/NixOS/nixpkgs/pull/310759#pullrequestreview-2129153331) is unadressed

Apologies, I did not notice this part.
Where should I write such documentation?

* We need more people to look at this and determine whether this is the direction we want to go or not since i don't consider myself influential enough to make that call. Should we advertise it on matrix?

Matrix and Discourse. I will open a post on Discourse.

[nixos-discourse]

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

https://discourse.nixos.org/t/nano-annoucement-create-a-field-inactivityreason-for-maintainers/48618/1

[willbush]

For someone to have write access to another repo in the NixOS org they have to be in the org. Adding oneself to the maintainer-list.nix triggers some automatic process that invites the person to the org. I only know this because it's a step I had to do when @infinisil gave me write access to nixpkgs-check-by-name. Any pruning of maintainer-list.nix should take this into account.

[AndersonTorres]

I will close this. It is not the suitable time to ponder about.