-
-
Notifications
You must be signed in to change notification settings - Fork 13.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
maintainers-list: create a field inactivityReason
#310759
maintainers-list: create a field inactivityReason
#310759
Conversation
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. |
f7d420c
to
92efa88
Compare
d88f277
to
4b4bbfd
Compare
83a4d7f
to
474f126
Compare
474f126
to
449f0c9
Compare
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. |
449f0c9
to
781d832
Compare
781d832
to
c2b6e49
Compare
Aleksana said
Rather than a boolean field, what if we make it |
ff45586
to
677457f
Compare
b00b4d3
to
3fe1f6c
Compare
isActive
inactivityReason
Done. What do you think, @pbsds ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like it! It could use an entry in the release notes, possibly some notes in the maintainer readme, and more opinions
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. |
2e3af20
to
7ff9b1f
Compare
7ff9b1f
to
0b513ff
Compare
0b513ff
to
624a992
Compare
This pr seems to be stuck in a limbo
|
624a992
to
1bd7c09
Compare
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*.
1bd7c09
to
aad34d1
Compare
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 = relaxed
sandbox = true
nix-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.