maintainers-list: create a field inactivityReason
#310759
Conversation
github-actions
bot
added
the
8.has: maintainer-list (update)
ofborg
bot
added
10.rebuild-darwin: 0
|
Why? |
|
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. |
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.
The idea is to mark cases of long term inactivity.
Agreed. |
|
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 |
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. |
The tooling can be updated to reflect this.
I am accumulating days cleaning up SDL-related packages in a state of abandonment. This is being bureaucratic as hell. |
|
Aleksana said
Rather than a boolean field, what if we make it |
AndersonTorres
changed the title
isActiveinactivityReason
|
Done. What do you think, @pbsds ? |
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. |
This is not the hardest thing on this planet.
Asking a dormant reviewer is not what I call transparency. |
|
This pr seems to be stuck in a limbo
|
It was a test and a proof of concept, I did it to catch errors.
Apologies, I did not notice this part.
Matrix and Discourse. I will open a post on Discourse. |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
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*.
|
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. |
|
I will close this. It is not the suitable time to ponder about. |
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:
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:
Description of changes
Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.