I gave it a shot, and it works, so with this change to githubPRs.py script: https://github.com/apache/lucene-solr/pull/2625 we can close all open PRs with a comment and label with a single command. The script can also easily be adapted to other use cases.
Jan > 8. des. 2021 kl. 01:33 skrev Jan Høydahl <[email protected]>: > > +1 to bulk commenting on the 274 open PRs with a standard message about the > need for new PRs. > We already have a "stale-closed" label in GitHub, so if we add that label to > all the issues they can safely be closed without information loss. > My script > https://github.com/apache/lucene/blob/main/dev-tools/scripts/githubPRs.py can > probably be tweaked to do these actions. It uses a python GitHub library and > already fetches all open PRs, and allows to pass a token, so I guess that the > token will also allow edits on behalf of the user. > > Jan > >> 2. des. 2021 kl. 17:55 skrev Michael Sokolov <[email protected]>: >> >> In this specific instance, I don't see the harm in leaving these >> issues there since the entire repo is essentially an archival artifact >> at this point. If we actually want to notify people that "hey your >> issue is in a dead zone, do you want to revive it? Here's how ..." we >> could maybe generate some emails? Although I really have no idea how >> we would accomplish that. >> >> In general, I'm in favor of cleaning up / closing issues that are >> clearly not going to be worked. >> >> For example in JIRA we have so many old issues that they can clutter >> up search results, making it much harder for new contributors >> (especially) to find "interesting" issues that might be relevant today >> and workable. I have heard various arguments for keeping these old >> issues: they represent an historical view of the project; "you never >> know" maybe they become relevant again; and this idea of not annoying >> people by arbitrarily closing their issue. These all have some >> validity, but I we have to strike a balance. I wonder if we can >> address them in another way. In JIRA can we keep these old issues >> while hiding them from default searches. Can we "archive" old issues >> in some way? Maybe there is a "Status" like Archived that is different >> from Closed. Anything but Open! >> >> >> On Mon, Nov 29, 2021 at 4:15 PM Mike Drob <[email protected]> wrote: >>> >>> I understand the frustrations around closing somebody’s PR as stale, but I >>> also think that there is value in informing the contributors I this is >>> never getting solved/fixed/looked at, if this is still important please go >>> over there instead. >>> >>> On Mon, Nov 29, 2021 at 1:55 PM Robert Muir <[email protected]> wrote: >>>> >>>> On Mon, Nov 29, 2021 at 2:49 PM Michael McCandless >>>> <[email protected]> wrote: >>>>> >>>>> Could we maybe instead bulk-add a comment explaining the split and how to >>>>> take the PR forwards if someone (in the future) has itch/time? >>>>> >>>>> I know we humans love to clean things up, but I think leaving such >>>>> "unclean" things open serves an important purpose. They all had >>>>> importance to at least one person at one point in time, and likely many >>>>> of them are still relevant if they piqued someones curiosity to dig back >>>>> into them. Closing them makes them harder to find for the future >>>>> developer. >>>>> >>>>> I'm sure some of them are already resolved/duplicates too. If only we >>>>> could divine which are which. >>>>> >>>>> >>>> >>>> +1, I'd rather not auto-close PRs. I'm always frustrated by this when >>>> I see it in other trackers. Is there a rush to close these for some >>>> reason? >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
