maintainers: remove one year inactive maintainer kiwi

[SuperSandro2000]

Description of changes

fyi @Kiwi (I don't expect an answer though)

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.

[maralorn]

Do you do this

• for all maintainers with more than one year inactivity
• all of them, but only when you accidentally notice
• for kiwi specifically because of special reasons?

Also how do you define inactivity? In theory all packages could be fine and no interaction was required? I don’t assume that happened here. I just don’t know whether we have a well-defined process.

[SuperSandro2000]

• all of them, but only when you accidentally notice

this one. I just checked bitwarden-desktop regarding an electron update and noticed that the existing updates where all done by one of the maintainers and then I checked the profile and didn't notice any activity in 2024 or 2023, so.. I guess that person is inactive for long enough to be removed.

Also how do you define inactivity?

If you don't have any github activity in over a year, you are definitely inactive.

[teto]

Is there an official written process somewhere ? It's nice that someone steps up to do the cleanup but it's a sensitive issue as the one year threshold and what consists in "activity" are debatable.

If you don't have any github activity in over a year, you are definitely inactive.

or he could have moved to another forge, contributed to github private repositories and chose to hide those and so on.

Issues seem to be taken into account in the github contribution graph (I checked as I was not sure):
https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-profile/managing-contribution-settings-on-your-profile/why-are-my-contributions-not-showing-up-on-my-profile

I hope you also emailed him as github pings could be filtered.

Another question is how long do we wait for an answer before a merge ?

[SuperSandro2000]

it's a sensitive issue as the one year threshold and what consists in "activity" are debatable.

or he could have moved to another forge, contributed to github private repositories and chose to hide those and so on.

True but nixpkgs activity cannot be and there is not much value in keeping inactive maintainers as that just gives a false hope that packages are maintainted and PRs for a package get reviewed. See the last 10+ bitwarden-desktop updates and the truly the maintainers are two other people.

I hope you also emailed him as github pings could be filtered.

Isn't that just another argument to remove inactive and unresponsive accounts?

Another question is how long do we wait for an answer before a merge?

Personally I don't think we need to wait that long.

[sternenseemann]

IMO it doesn't make sense to do this without an established policy. Also, having a stale maintainer entry is strictly more useful than having none at all.

[amarshall]

I think that leaving maintainers who have become absent from the project causes two issues:

• Possible confusion and delay for committers, as they would generally (I think) want to wait for review from a maintainer if there is one. So either they end up waiting longer for someone who is, again, absent, or they have to check to see how active they are each time to make a decision based on that. Caveat being I myself am not a committer.
• It misleads others that a pkg is maintained, when in fact it may not be.

So I’m not sure I agree “having a stale maintainer is strictly more useful than having none at all”.

Certainly though having a formal process would be best.

[amarshall]

Specific to bitwarden-desktop, kiwi has not made commits to it since their initial packaging of it.

[eclairevoyant]

[committers] would generally (I think) want to wait for review from a maintainer if there is one

Realistically there is no onboarding for committers, and even most contributors are aware that maintainers aren't necessarily active despite being listed, so I wouldn't generalise along these lines for committers.

But I agree that it'd cause confusion for end users. Maintainership should simply be an accurate reflection of the state of care for the package, not some kind of exclusive ownership - former maintainers are welcome to contribute without being maintainer, or come back as maintainer, should they choose so in the future.

Besides, maintainership is fluid, so as long as maintainers are notified in such removal PRs after extended inactivity, and don't respond for (say) a week after the tag, I don't see a major issue personally.

Certainly though having a formal process would be best.

which is pending the rfc

[amarshall]

Since it wasn’t linked above, I assume this is the RFC in question: NixOS/rfcs#167

[SuperSandro2000]

Since we have done similar things in the past already, I don't see the necessity of waiting for the RFC which will just delay the unavoidable.

[7c6f434c]

Speaking of documented formal procedures:

https://github.com/NixOS/nixpkgs/blob/master/maintainers/README.md#how-to-lose-maintainer-status

[maralorn]

Well then, this PR seems fine.

[doronbehar]

Speaking of documented formal procedures:

master/maintainers/README.md#how-to-lose-maintainer-status

Linking the PR that added that text for reference (from git blame):

#250344