Skip to content
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

[RFC] Give stale PRs 2 weeks to show signs of life #36253

Closed
0x5c opened this issue Mar 21, 2022 · 9 comments
Closed

[RFC] Give stale PRs 2 weeks to show signs of life #36253

0x5c opened this issue Mar 21, 2022 · 9 comments

Comments

@0x5c
Copy link
Contributor

0x5c commented Mar 21, 2022

... then nuke the ones that didn't.

Rationale

The backlog is enormous, scary, and full of PRs that don't meet quality requirements, are waiting (for months) for requested changes, and/or have generally been abandoned. There's even PRs that no longer have an author (#29665, #30909).
This idea was mentioned multiple times in the IRC channel by multiple people, with a positive response.

How

  1. Set a cutoff amount of inactivity, ie: 6 months
  2. Get the list of PRs matching that inactivity to a file, ie: gh pr list -L 2000 -S 'updated:<=2021-09-20' > file.tsv
    The issue number is the first column
  3. Using a script and the GH API, do for each PR in the list:
    1. Apply the already-existing inactive tag
    2. Send a message explaining that the PR will be closed in two weeks if it doesn't get any activity.
  4. Wait two weeks
  5. Close marked PRs that didn't get any updates.
    This part could be done automatically if searching for label:inactive updated:<=[date of script run]T[time of script run], although it will miss PRs where the activity was just "I don't use void anymore". I suspect this will not be a big problem considering how dead the backlog is.
@subnut
Copy link
Contributor

subnut commented Mar 21, 2022

I think first of all we should remove the obsolete PRs, i.e. Those PRs whose newer versions of the package have been accepted already. Then, we should either take over the PRs opened by ghost or close them. Then, we should do what has been mentioned above.

Also, I think the wait time should be increased a bit. Three weeks, maybe?

@0x5c
Copy link
Contributor Author

0x5c commented Mar 21, 2022

I think first of all we should remove the obsolete PRs, i.e. Those PRs whose newer versions of the package have been accepted already.

The obsolete PRs are for the most part closed, as tracked in #36116. Both remaining ones have unmerged patches/fixes. The libsigrok one is has a better fix in #36144, but it is yet to be known if the binfmt one is actually needed.

@tibequadorian
Copy link
Contributor

I'm not a fan of closing PRs just because of inactivity because it helps others to build upon these.
But I'm all in for tagging these PRs to be able to filter them out using -label:inactive

@classabbyamp
Copy link
Member

People can still build upon closed PRs, they don't just disappear once closed. The inactive label can be used on closed PRs to differentiate closed=rejected and closed=stale

@0x5c
Copy link
Contributor Author

0x5c commented Mar 22, 2022

@tibequadorian Closing PRs doesn't block anyone from discussing those PRs, nor does it make the PR's content disappear. It all remains there for anyone else to build upon, just without the immense strain on the backlog. If anything, an open PR can discourage others from making new and updated PRs for the same things. And as Abby said, the label doesn't have to be removed from PRs once they are closed for inactivity, and the whole process involves sending a comment explaining why the PR got closed.

@tibequadorian
Copy link
Contributor

I know the content doesn't disappear but the list of closed PRs (which is 40x bigger and growing) is usually not considered when searching for a useful PR to build upon. Not least because GitHub filters for open PRs automatically. I'd rather just mark them as inactive and keep them open as long as they are useful to others.

@0x5c
Copy link
Contributor Author

0x5c commented Mar 22, 2022

It seems to me it would be more helpful to direct users to the full search, or accept that most of them (especially the new packages) don't meet the quality requirements (of package and or PR), on top of being outdated, and wouldn't be a good base for new PRs. Keep in mind it's not "the old PRs" but inactive PRs which this target; the old but still active PRs generally meet quality requirements and are kept updated by their authors.

@0x5c
Copy link
Contributor Author

0x5c commented Mar 22, 2022

Yet another problem with those PRs: the Github action logs are long gone, meaning we can't even know what the failures were

@0x5c
Copy link
Contributor Author

0x5c commented Apr 11, 2022

#36462 has been merged (d6fc551), taking care of this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants