mirror of
https://github.com/qbittorrent/qBittorrent.git
synced 2026-03-02 22:57:32 -05:00
[Tool] Batch close old issues #10312
Labels
No labels
Accessibility
AppImage
Bounty
Build system
CI
Can't reproduce
Code cleanup
Confirmed bug
Confirmed bug
Core
Crash
Data loss
Discussion
Docker
Documentation
Duplicate
Feature
Feature request
Feature request
Feature request
Filters
Flatpak
GUI
Has workaround
I2P
Invalid
Libtorrent
Look and feel
Meta
NSIS
Network
Not an issue
OS: *BSD
OS: Linux
OS: Windows
OS: macOS
PPA
Performance
Project management
Proxy/VPN
Qt bugs
Qt6 compat
RSS
Search engine
Security
Temp folder
Themes
Translations
Triggers
Waiting diagnosis
Waiting info
Waiting upstream
Waiting web implementation
Watched folders
WebAPI
WebUI
autoCloseOldIssue
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/qBittorrent#10312
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @sledgehammer999 on GitHub (Apr 27, 2020).
@qbittorrent/bug-handlers @qbittorrent/frequent-contributors
I have coded this tool in the past couple days.
It can close old issues, leave a comment, apply a label, lock the issue and skip issues with certain labels.
After I apply my other tool mentioned in #12101 I intend to run this tool on the repo with the following arguments:
I chose
2019-05-06T00:00:00Zsemi-randomly. It is the day after the v4.1.6 release which was about 1 year ago. I figured that all those issues can be closed instantly.PS: This will not close issues that were updated after that timepoint. eg by someone leaving a comment, applying a label etc.
A dry-run of the above cmdline shows that 819 will be closed.
Second Phase
After the above procedure, I plan the following for all issues between v4.1.6 and v4.2.0:
Do you have any comments on the above before I proceed?
@sledgehammer999 commented on GitHub (Apr 27, 2020):
I also wonder if "feature requests" that haven't been implemented until 2 years are worth keeping in the repo? I am pondering if I should run this tool a second time and not skip "feature requests" that are more than 2 years old.
Any thoughts on this?
@ghost commented on GitHub (Apr 28, 2020):
The thing is most of the feature requests are being ignored.
So I see no point in treating feature requests differently. Since these will remain stalled forever like old issue.
@FranciscoPombal commented on GitHub (Apr 28, 2020):
@sledgehammer999
Why not use the stale bot for the second phase? It can accomplish all the steps you listed for that phase. Then we can just leave it running, exempting issues such as "Feature request", "Security" and the like, and/or issues that are part of milestones/projects or that have some project member assigned to.
As for the feature requests, I am against closing them. I think we should leave them all open, and then start to prioritize them according to popularity. I can start to do this and formulate a more structured plan about this once the major cleaning has been completed.
@FranciscoPombal commented on GitHub (Apr 28, 2020):
@sledgehammer999
I also vote for a more fleshed-out locking message, like:
This is to avoid users complaining about "you're being lazy closing/locking old issues instead of fixing things!". It's better to provide at least a small justification for this action IMO.
Speaking of issue templates, can you take a look at https://github.com/qbittorrent/qBittorrent/pull/12574? For the sake of sanity, I'd like to have something like this merged sooner rather than later. It's getting really tiring to deal with all the low-effort bug reports and having to constantly ask for logs and settings.
@FranciscoPombal commented on GitHub (Apr 29, 2020):
@sledgehammer999
Another very important detail: you should also run the tool to lock issues that are already closed and have received no activity since some date (it can be the same date you mention in the OP).
This is absolutely essential to curb the necroing problem.
The locking message could be almost the same as the message above, but with the first sentence changed to:
@xavier2k6 commented on GitHub (Sep 12, 2020):
Breakdown of "Labelled Issues Only" with "Open" status
Applicable to 45x qBittorrent Issue Tracker Labels
Saturday, Sep 12, 2020 16:50 GMTMonday, Oct 12, 2020 21:00 GMT(Date/data will change periodically when updated)
NOTE:
(Some Issues may have more than 1 designated Issue Tracker label assigned)
@xavier2k6 commented on GitHub (Sep 12, 2020):
Breakdown of "Labelled Issues Only" (Without "Feature request" label applied)
Saturday, Sep 12, 2020 16:50 GMTMonday, Oct 12, 2020 21:00 GMT(Date/data will change periodically when updated)
NOTE:
(Some Issues may have more than 1 designated Issue Tracker label assigned)
Feature request (Only) has no other label applied.
@xavier2k6 commented on GitHub (Sep 12, 2020):
Current "Open Issues" status of qBittorrent Issue Tracker
(Date/data will change periodically when updated)
Saturday, Sep 12, 2020 16:50 GMT
ISSUES
2,877 are Open across 116 pages (1 page = 25 issues)
Breakdown of "Labelled Issues Only" with "Open" status
Breakdown of "Labelled Issues Only" (Without "Feature request" label applied)
Pinned
3
linked with PR 12697
Linked with Pull Requests
24 linked with Pull Requests
Assigned to milestones
11 to milestone v3.2.1
3 to milestone v3.3.10
1 to milestone 4.1.10
3 to milestone 4.2.6
Assigned to Team Member
12 to FranciscoPombal
13 to glassez
3 to zeule
2 to Piccirello
Could be potentially closed
704
--cutoff-timepoint=2019-05-06T00:00:00Z--skip-label="Feature request"Unlabelled
779 remain Unlabelled across 32 pages (1 page = 25 issues)
Action Plan
In an effort to continue/aid the work of this tool:
Task No.1:
Review/close as per https://github.com/qbittorrent/qBittorrent/issues/12679#issue-607926396
704
--cutoff-timepoint=2019-05-06T00:00:00Z--skip-label="Feature request"487 Unlabelled
Task No.2:
Label remainder of Unlabelled Issues
@FranciscoPombal & @thalieht "IF" possible could/would each of you tackle these & label 1 page of 32 per day
(1 page = 25 issues)
(Task 1 above, should actually handle alot of them)
As a suggestion, start at either end & meet in the middle
@FranciscoPombal
Newest Unlabelled Issues
@thalieht
Oldest Unlabelled Issues
Task No.3:
Review All assigned/linked Issues
Task No.4:
Update
Breakdown of "Labelled Issues Only" with "Open" status
Breakdown of "Labelled Issues Only" (Without "Feature request" label applied)
Task No.5:
@thalieht commented on GitHub (Sep 12, 2020):
I've been through all issues a couple times and as far as i'm concerned, unlabeled ones remained thus because no label seemed appropriate for them (obviously there are surely some i missed). For example https://github.com/qbittorrent/qBittorrent/issues/7095 what label would be fitting for that? Other than that, there are many where i simply don't know if it's libtorrent, core or something else, and then there are those where user error is suspect, and from my experience, it's too late to disprove that (no replies after all this time).
Feature requests are timeless, no? The main devs may never implement most of them but it doesn't mean some new contributor won't, just like it happened with the tags subsystem.
@xavier2k6 commented on GitHub (Sep 12, 2020):
well sledge was running/going to run his tool to close all issues equal to/below
2019-05-06& without thelabel:"Feature request"reference https://github.com/qbittorrent/qBittorrent/issues/12679#issue-607926396. (Take from that what you will, I had it as Task No.1)At this stage, the
trackerhas seriously got out of hand & this is why I've tried to get some grasp on it/implement what he had suggested/intended.Label/close what you can & anything that is left open/unlabelled can be decided on collectively later on....
Also, (libtorrent 1.1.x series has been dropped) (v4.2.x has been using 1.2.x.x)
Ref Remove RC_1_1 support #12278
PR Bump requirement to libtorrent 1.2
With everything labelled/organized:
Breakdown of "Labelled Issues Only" with "Open" status & Breakdown of "Labelled Issues Only" (Without "Feature request" label applied) should make things easier to review as all labels are in one place & only take in to account "issues", (label names are links with filters applied)
I'd have to agree not to close the 2yr+ "Feature requests".
#4163 for example was created on
24 Nov 2015but won't see full libtorrent implementation/support until2.xor possibly3.xreference: https://github.com/arvidn/libtorrent/pull/4123#issuecomment-676064126 & https://github.com/arvidn/libtorrent/pull/4123#issuecomment-676074545@FranciscoPombal commented on GitHub (Sep 13, 2020):
@xavier2k6
Thanks for the breakdown and the initiative.
I actually posted a very similar action plan in the team page (https://github.com/orgs/qbittorrent/teams/bug-handlers/discussions) all the way back in February. However, most of the plan got stalled due to @sledgehammer999's absence, namely in what concerns bulk actions like closing old issues. Fortunately, while the issue count situation has not improved much, at least it hasn't got much worse. Even at the current pace, I expect we'll still be below 3k issues by the end of the year. I must have closed several hundreds of issue so far.
One of the things that is much needed as well is the issue template rework: https://github.com/qbittorrent/qBittorrent/pull/12574.
@thalieht
I think we need a new labeling/triaging/priority system. I'll try to work something out. In the meantime, there's around 50 issues that should be low-hanging fruit to close - they were marked as
Duplicateby you at some point, but never actually linked them to their duplicates or closed them as such. Could you please go through them, link to their duplicates and close them? Since it was you who originally marked them as duplicate, you must have a better idea of their duplicates:https://github.com/qbittorrent/qBittorrent/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3Aduplicate
Also, I would ask you to please lock closed issues. Otherwise many people just will just necro them at some point without providing enough relevant new information.
@FranciscoPombal commented on GitHub (Sep 13, 2020):
@thalieht Here's some revised boilerplate from https://github.com/qbittorrent/qBittorrent/issues/12679#issuecomment-620728459 to help close old issues. You can save it and apply it automatically using GitHub's "Save reply" feature: https://github.com/settings/replies
@xavier2k6 commented on GitHub (Sep 13, 2020):
Since I'm not a team member, I'm not privy to that info....
#11161 seems to have been abandoned?!
That may be so, that's why I did the breakdown (one of which removes the "feature request" which gives an actual better indication of the issues) & was trying to have everything currently labelled as it makes it easier to go through for review/closing etc.
@thalieht commented on GitHub (Sep 13, 2020):
I think we'd all be wasting our time if the/a bot is still considered. So unless sledgehammer999 or whoever becomes the new maintainer explicitly says that the idea is abandoned, i'll refrain from doing such a thing.
Sorry but i'm lazy :). If there was a close+lock button i might consider it. I think it's preferable to have a very small % of issues being necro'ed than having to perform 2 clicks on every last one of them, one of which is most probably pointless (IMO). Oh i don't remember if i mentioned it again but personally, i see nothing wrong with necro-ing. I never understood why some people hate it.
I'll see if i can find the duplicates.
@FranciscoPombal commented on GitHub (Sep 13, 2020):
@thalieht
Of course a bot would be the preferred way of carrying out this task all the way to completion, but recently you've already taken to closing issues with messages like "most likely fixed" and "useless information provided" (effectively doing part of the bot's work), so might as well use the nice boilerplate. WIth GitHub saved replies, it's probably faster as well, just 3 clicks: 1 - click icon; 2 - click reply; 3 - click comment. Ideal for lazy people :)
This is a joke, right? The cost of 2 or 3 extra measly clicks is more than offset by the fact you won't receive a useless notification for a necro'ed thread with new comments that do not present any new useful or actionable information in the future. It's not about the % of issues being necro'ed, it's about the % of (useless) traffic coming from them compared to new issues/new developments on currently open issues.
It's significant enough to be a nuisance for those that are subscribed to all repo notifications, such as me. If anyone wants/needs to resurrect an issue topic, they should open a new issue with full information as requested by the issue template, to save everyone's (especially the contributor's) time. The user just has to put in the effort to write a new issue, the contributors "have" to answer to multiple ones.
@sledgehammer999 themselves understood the importance and necessity of locking closed issues, and designed the tool/plan to do exactly that:
(emphasis mine)
I see you've resolved more than half of them already, great job 👍
@FranciscoPombal commented on GitHub (Sep 13, 2020):
@xavier2k6
https://github.com/qbittorrent/qBittorrent/pull/12574 is effectively an implementation of it. I'm shouting fire in a crowded theater to get it merged, but no one is moving (I think because the decision to merge such a PR is implicitly understood to be the sole responsibility of the maintainer, but they're away and they're not the ones who manage the issue tracker). That issue you linked is a good reference, if others want more template categories such as those mentioned in that issue, I can add them.
The thing is, it is useless to label issues that would get closed anyway by the bot/tool due to the being too old. That is the real blocker. Old issues need to be closed first - all the rest comes after. I only mention the new labeling system now because I think we might need to start investing in this effort that in parallel; it has been so long, that many new (as in, posted post-February 2020) have started to accumulate unlabeled. I've always done my best to label all of the new issues since then, but indeed, with the current label system, sometimes I too face the problem of not being able to find a suitable label for some of the issues.
EDIT:
Here's this year's unlabeled issues so far: https://github.com/qbittorrent/qBittorrent/issues?q=is%3Aissue+is%3Aopen+created%3A%3E%3D2020-01-01+no%3Alabel
I'll see what I can do.
@xavier2k6 commented on GitHub (Sep 13, 2020):
**Issues related to OP "user accounts" that have been deleted by github/now represented by "ghost"
what should be done with these? (x60)
#416 #428 #516 #590 #1167
#1376 #1788 #2450 #2680 #3650
#3671 #3672 #3996 #4230 #4374
#4475 #4502 #4562 #5086 #5236
#5449 #5798 #6668 #7348 #7391
#7557 #7658 #7694 #7776 #7811
#7941 #7999 #8111 #8167 #8270
#8413 #8462 #8487 #8492 #8519
#8613 #8689 #8738 #8882 #8911
#9079 #9362 #9431 #9588 #9607
#9715 #10015 #10018 #10059 #10110
#10259 #10310 #10311 #10767 #11755
@xavier2k6 commented on GitHub (Sep 13, 2020):
Fair enough, at least now though we have some "direction" & "drive" while there's no new release to add more workload, otherwise I think we'd be just going around in circles....
Now, seems the right time to get a grasp on things....
@FranciscoPombal commented on GitHub (Sep 13, 2020):
@xavier2k6
The validity of some of those issues is not contingent on the OP's user account still existing (e.g. feature requests). However, some bug reports which only affect the OP can be closed, if they can't reasonably be reproduced. I'll see what I can do about them. Thanks for bringing this to my attention.
With all due respect, there are some internal team matters that you're not aware of that are stalling progress on this matter (expect to know more about this by the end of the year). Sadly, right now it's not possible to bring you into the team, even though you would definitely join it in some capacity, if it were up to me. Your initiative is much appreciated nonetheless, and you can rest assured that resolving this matter is still one of my top priorities.
@xavier2k6 commented on GitHub (Sep 13, 2020):
No problem, Just trying to do the best I can to make things easier (unless I'm making it worse, lol)
Had to search page by page with
CTRL+Fforghostas searching withauthor:ghostdoesn't relinquish any results, just as a heads-up/bare in mind.Appreciate that & totally understand.
Also, #11175 & #9511 can probably be closed as well since there is some more active focus now no matter how small....
@FranciscoPombal commented on GitHub (Sep 13, 2020):
@xavier2k6
Ok, I went through them all. I was able to close some of them, not others. I tweaked the titles/labels where needed.
Here's what's left open:
#416 #428 #516 #590 #1167
#1376 #3650 #3671 #3672 #3996
#4374 #4475 #5086 #5236 #5449
#7348 #7557 #7941 #7999 #8111
#8492 #8738 #9079 #9715 #10059
#10110 #10311 #11755
There's a few of these I might close still, depending on whether I can reproduce them tomorrow.
@xavier2k6 commented on GitHub (Sep 14, 2020):
another tip to aid review/labelling etc is to click a "user name" to view what issues that user has created to date as sometimes they can be similar to ones they've already opened previously/duplicate of something that's already reported/taken care of by now or have more than one issue reported.
examples:
spirulin
eurobank
slrslr
Snurre86
@FranciscoPombal commented on GitHub (Sep 14, 2020):
@xavier2k6
30 remaining.
@ghost commented on GitHub (Sep 30, 2020):
Kind of off-topic but some important questions regarding this issue tracker:
Has the maintainer abandoned ship or is there any news regarding his disappearance?
Who'll become the new maintainer, if any?
Also, why there isn't much concern regarding this(the disappearance)? Does it happen quite often?
@FranciscoPombal commented on GitHub (Sep 30, 2020):
@an0n666
There is concern, this matter is being discussed in the private team page. There are some people who aren't on there that probably should be, but only the maintainer can add them, unfortunately.
Contingency plans are in the works. Expect to hear more about this by the end of the year, maybe earlier.
To be clear, while the maintainer's absence is certainly not ideal, the project is not dead or dying.
@xavier2k6 commented on GitHub (Sep 30, 2020):
planning to do a status update at wknd 02-04 OCT (time permitting.)
@FranciscoPombal commented on GitHub (Oct 1, 2020):
@xavier2k6
What do you mean? Can you please elaborate about what you are working on?
@xavier2k6 commented on GitHub (Oct 1, 2020):
updating of this: https://github.com/qbittorrent/qBittorrent/issues/12679#issuecomment-691508394 this: https://github.com/qbittorrent/qBittorrent/issues/12679#issuecomment-691508412 & this: https://github.com/qbittorrent/qBittorrent/issues/12679#issuecomment-691510714 with latest figures etc.
@xavier2k6 commented on GitHub (Oct 12, 2020):
updated https://github.com/qbittorrent/qBittorrent/issues/12679#issuecomment-691508394 & https://github.com/qbittorrent/qBittorrent/issues/12679#issuecomment-691508412 with latest figures but didn't update https://github.com/qbittorrent/qBittorrent/issues/12679#issuecomment-691510714 as maintainer is back - will continue his own action plan.
sledgehammer999 On a personal note, really glad to see you back & that you are ok!!
I hope my actions here didn't have too much of a negative effect in what you had previously decided etc., you would've probably noticed anyway that the ghost issues would've been excluded in the search filters/batch tool
@xavier2k6 commented on GitHub (Oct 16, 2020):
Tuesday December 3rd 2019 - qBittorrent v4.2.0 release
Windows 7Windows XP 5.1.2600#7531 #9665
Below may need a follow up though...... because of https://github.com/qbittorrent/qBittorrent/issues/11399#issuecomment-546679312 & https://github.com/qbittorrent/qBittorrent/issues/11399#issuecomment-546689654
#11399
@FranciscoPombal commented on GitHub (Oct 16, 2020):
@xavier2k6
Typo? It should be Windows XP, right?https://github.com/qbittorrent/qBittorrent/issues/12679#issuecomment-710292894@xavier2k6 commented on GitHub (Oct 16, 2020):
It's a snippet of 4.2.0 Release History from official website
@FranciscoPombal commented on GitHub (Oct 16, 2020):
@xavier2k6
Right, it's wrong... Feel free to submit a PR fixing that both here in the changelog as well as the website.https://github.com/qbittorrent/qBittorrent/issues/12679#issuecomment-710292894@xavier2k6 commented on GitHub (Oct 16, 2020):
How so? (Am I missing something obvious here?)
Doesn't that signify support for windows versions less than 7 are no longer supported so that means
windows Vistatoo but I just haven't looked for issues of that build yet...@FranciscoPombal commented on GitHub (Oct 16, 2020):
@xavier2k6 Oh God, I'm so sorry, I kept reading
<=instead of just<, and forgot that Vista even existed for some reason. It is indeed correct. Sorry for the confusion!@xavier2k6 commented on GitHub (Oct 16, 2020):
windows vista#8878
#547 doesn't seem to be longer relevant/close?
@jagannatharjun commented on GitHub (Oct 18, 2020):
why not https://github.com/marketplace/stale ?
@xavier2k6 commented on GitHub (Oct 18, 2020):
#11924
Edit: similar #11363
@xavier2k6 commented on GitHub (Oct 23, 2020):
qBittorrent v4.3.0 Released (Sunday October 18th 2020 )
Support for libtorrent 1.1.x is dropped
This makes 4.2.0 (Released Dec 3rd, 2019) the NEW MINIMUM supported version.
(Unless PR https://github.com/qbittorrent/qBittorrent/pull/13511 raises libtorrent requirement to >= 1.2.10)
>=4.2.0 use the libtorrent 1.2.x series<=4.1.9.1 use libtorrent 1.1.xIf we take
2019-12-04T00:00:00Z(day after 4.2.0) along with-label:"Feature request"as a base for closing issues.We could potentially close:
524 x Unlabelled
NOTE:
(Some Issues may have more than 1 designated Issue Tracker label assigned)
@FranciscoPombal commented on GitHub (Oct 23, 2020):
@xavier2k6 I took care of the 6 "Invalid + Not an issue" issues and edited you post accordingly.
@xavier2k6 commented on GitHub (Oct 23, 2020):
Updated https://github.com/qbittorrent/qBittorrent/issues/12679#issuecomment-715285280 with new info/removed closed/taken care of, thanks @FranciscoPombal & general clean-up/aesthetics
@sledgehammer999 commented on GitHub (Oct 29, 2020):
I have updated the tool and run it. It seems to have closed 594 old issues.
@FranciscoPombal commented on GitHub (Oct 29, 2020):
@sledgehammer999
Just finished double-checking those that i was mentioned/participating in - there are none that I would like to reopen 👍.
However, only 594 closed is not enough IMO. We need either a more aggressive time interval or better heuristics. For example, detecting versions in the OP < 4.2.0. This could be done by simply checking for one, and only one instance of the string
3.x.xor4.1.x/4.0.x. The reason for "only one" is because if more than one version number is present, it's most likely because there is a comparison being made, to point out that "it used to work"/"it still happens", etc.@sledgehammer999 commented on GitHub (Oct 29, 2020):
The 594 were the ones that were in the "instant close" category.
There are others that need 2-phase approach. Issue a warning comment, some days of inactivity pass, go back and close those. I want to do that for everything up until the previous day 4.2.5 was released.
I am tempted of instead of writing another tool, to just let the stale bot run for a few days until those issues are closed by it.
(Because I don't want a rolling closing of issues by the stale bot)
@sledgehammer999 commented on GitHub (Oct 29, 2020):
@FranciscoPombal don't reopen this issue. It's purpose is done.
@xavier2k6 commented on GitHub (Oct 29, 2020):
@sledgehammer999 @FranciscoPombal please review https://github.com/qbittorrent/qBittorrent/issues/12679#issuecomment-715285280 again as (although not currently updated due to running of tool) 557 could be closed.....
@xavier2k6 commented on GitHub (Nov 30, 2020):
@sledgehammer999 The
label:autoCloseOldIssueis still showing up (well a few of them) in "is:open" search filter on tracker especially when sorting by oldest,some examples:
https://github.com/qbittorrent/qBittorrent/issues?q=is%3Aopen+is%3Aissue+no%3Alabel+sort%3Acreated-asc
https://github.com/qbittorrent/qBittorrent/issues?q=is%3Aopen+is%3Aissue+sort%3Acreated-asc+-label%3A%22Feature+request%22+
If I apply
-label:autoCloseOldIssueapprox 32 issues disappear from "is:open" (although I think that may be taking in to account the issues created by accounts that are now ghost)https://github.com/qbittorrent/qBittorrent/issues?q=is%3Aopen+is%3Aissue+sort%3Acreated-asc+-label%3AautoCloseOldIssue+
Does the labelling system need to be amended??
Here are the ones, that seem to show up:
#1242 #6646 #1474 #1817 #6632
@xavier2k6 commented on GitHub (Dec 17, 2020):
@FranciscoPombal Could you take a look at https://github.com/qbittorrent/qBittorrent/issues/12679#issuecomment-735888627 there was something like this before & when it was commented on or something like that.......it closed properly......perhaps a re-open/close may fix it?!
@FranciscoPombal commented on GitHub (Dec 17, 2020):
@xavier2k6
Seems the scripts missed out on closing quite a few old issues, but that is a problem for another time.
Tthis looks good to me:
https://github.com/qbittorrent/qBittorrent/issues?q=is%3Aopen+is%3Aissue+sort%3Acreated-asc+label%3AautoCloseOldIssue
i.e., there are no open issues that are labeled with the auto close label.
As for the closed issues that were still shown up with the
is:openfilter, I think I've now fixed all instances of that.@xavier2k6 commented on GitHub (Dec 17, 2020):
@FranciscoPombal Thanks, seem to be fixed now alright from what I've checked.
I think the scripts didn't take in to account the
ghostaccounts & the parameters will have to be changed the next time the tool/script is used asupdatedis practically useless now over the wholebountyinitiative....Will have to use something like e.g.
created:<=2020-04-26T00:00:00Z(day after 4.2.5 release)@xavier2k6 commented on GitHub (Jul 19, 2023):
@sledgehammer999 Do you plan to do another run of this batch tool in the near future?