[Tool] Batch close old issues #12679

sledgehammer999 · 2020-04-27T23:51:08Z

@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:

 --cutoff-timepoint=2019-05-06T00:00:00Z --apply-label="autoCloseOldIssue" --skip-label="Feature request" --comment="This issue is automatically closed for being very old with no activity.\nIf you still experience it with the latest qBittorrent version then feel free to open a new issue." --lock

I chose 2019-05-06T00:00:00Z semi-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:

Non updated issues till today, will be marked with a label
A comment will be left, informing users for the imminent issue closing
After 10-15 days, the marked ones will be rechecked. If no activity was present they will be autoclosed and locked

Do you have any comments on the above before I proceed?

The text was updated successfully, but these errors were encountered:

sledgehammer999 · 2020-04-28T00:42:00Z

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 · 2020-04-28T04:43:35Z

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 · 2020-04-28T16:08:39Z

@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 · 2020-04-28T16:51:20Z

@sledgehammer999
I also vote for a more fleshed-out locking message, like:

This issue has been closed and locked for being too old, and thus either most likely resolved in recent versions or no longer applicable.
If you experience the reported problem or similar in the latest version, please open a new issue report with the requested information in the issue template.

A new issue report with relevant updated data gathered from the latest version is preferable to necroing an old report with a comment like "still happens in version x.y.z", even if you think the bug is the same, or suspect of a regression.
Due to the changes made to the qBittorrent code and its dependencies over time, the exact cause of your problem could be totally different than the original one, despite the visible symptoms of the bug being similar.
Thus, providing relevant updated information is crucial to find and fix the root cause of a recurrent problem or regression.

Thank you for your contributions.

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 #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 · 2020-04-29T11:59:12Z

@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:

This issue has been locked for being closed, which means the original problem is considered to be resolved.

xavier2k6 · 2020-09-12T15:47:57Z

Breakdown of "Labelled Issues Only" with "Open" status

Applicable to 45x qBittorrent Issue Tracker Labels

Saturday, Sep 12, 2020 16:50 GMT Monday, Oct 12, 2020 21:00 GMT

(Date/data will change periodically when updated)

Issue Tracker Label x15	Open	Issue Tracker Label x15	Open	Issue Tracker Label x15	Open
Accessibility	5	GUI	331	PR abondoned	0
Backport	0	Help wanted	19	PR waiting author	0
Build system	15	Hotfix	0	Project management	19
Can't reproduce	44	Invalid	6	Proxy/VPN	41
Code cleanup	8	Libtorrent	43	Qt bugs	24
-	-	-	-	-	-
Confirmed bug	79	Look and Feel	44	RSS	167
Core	128	Meta	7	Search engine	45
Crash	133	Network	115	Security	3
Data loss	13	Not an issue	13	Temp folder	58
Discussion	30	NSIS	3	Translation	11
-	-	-	-	-	-
Documentation	10	OS: Linux	65	Waiting upstream	11
Duplicate	0	OS: macOS	69	Waiting Web implementation	1
Easy to fix	13	OS: Windows	127	WaitingInfo	68
Feature request	851	Performance	88	WebAPI	43
Feature	7	PPA	2	WebUI	117

NOTE:

(Some Issues may have more than 1 designated Issue Tracker label assigned)

xavier2k6 · 2020-09-12T15:48:05Z

Breakdown of "Labelled Issues Only" (Without "Feature request" label applied)

Saturday, Sep 12, 2020 16:50 GMT Monday, Oct 12, 2020 21:00 GMT

(Date/data will change periodically when updated)

Issue Tracker Label x15	Open	Issue Tracker Label x15	Open	Issue Tracker Label x15	Open
Accessibility	1	GUI	227	PR abondoned	0
Backport	0	Help wanted	17	PR waiting author	0
Build system	13	Hotfix	0	Project management	16
Can't reproduce	44	Invalid	6	Proxy/VPN	38
Code cleanup	7	Libtorrent	32	Qt bugs	23
-	-	-	-	-	-
Confirmed bug	75	Look and Feel	34	RSS	110
Core	106	Meta	7	Search engine	22
Crash	133	Network	111	Security	2
Data loss	13	Not an issue	11	Temp folder	50
Discussion	26	NSIS	1	Translation	11
-	-	-	-	-	-
Documentation	9	OS: Linux	62	Waiting upstream	4
Duplicate	0	OS: macOS	62	Waiting Web implementation	1
Easy to fix	2	OS: Windows	112	WaitingInfo	66
Feature request (Only)	542	Performance	87	WebAPI	38
Feature	3	PPA	1	WebUI	84

NOTE:

(Some Issues may have more than 1 designated Issue Tracker label assigned)
Feature request (Only) has no other label applied.

xavier2k6 · 2020-09-12T16:08:35Z

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

Highlight torrents with no working trackers/Tracker status column/Trackers not working filter/"Unregistered torrent" filter #9849
linked with PR 12697
GUI performance with many thousands of torrents - transfer list, icons, and more #13304
SOCKS5 proxy disconnect issue due to insufficient retries #12583

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 [Tool] Batch close old issues #12679 (comment)
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 · 2020-09-12T21:25:41Z

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 #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).

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.

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 · 2020-09-12T22:01:41Z

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 #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).

well sledge was running/going to run his tool to close all issues equal to/below 2019-05-06 & without the label:"Feature request" reference #12679 (comment). (Take from that what you will, I had it as Task No.1)

At this stage, the tracker has 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 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.

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.

I'd have to agree not to close the 2yr+ "Feature requests".
#4163 for example was created on 24 Nov 2015 but won't see full libtorrent implementation/support until 2.x or possibly 3.x reference: arvidn/libtorrent#4123 (comment) & arvidn/libtorrent#4123 (comment)

FranciscoPombal · 2020-09-13T12:03:47Z

@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: #12574.

@thalieht

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).

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 Duplicate by 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 · 2020-09-13T12:18:11Z

@thalieht Here's some revised boilerplate from #12679 (comment) to help close old issues. You can save it and apply it automatically using GitHub's "Save reply" feature: https://github.com/settings/replies

This issue has been closed and locked for being too old, and thus either most likely resolved in recent versions or no longer applicable.
If you experience the reported problem or similar in the **latest** version, please open a new issue report with the requested information in the issue template.

A new issue report with relevant updated data gathered from the latest version is preferable to necroing an old report with a comment like "still happens in version x.y.z", even if you think the bug is the same, or suspect of a regression.
Due to the changes made to the qBittorrent code and its dependencies over time, the exact cause of your problem could be totally different than the original one, despite the visible symptoms of the bug being similar.
Thus, providing relevant updated information is crucial to find and fix the root cause of a recurrent problem or regression.

Thank you for your contributions.

xavier2k6 · 2020-09-13T12:19:36Z

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.

Since I'm not a team member, I'm not privy to that info....

One of the things that is much needed as well is the issue template rework: #12574.

#11161 seems to have been abandoned?!

I think we need a new labeling/triaging/priority system.

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 · 2020-09-13T13:14:44Z

@thalieht Here's some revised boilerplate from #12679 (comment) to help close old issues. You can save it and apply it automatically using GitHub's "Save reply" feature

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.

Also, I would ask you to please lock closed issues.

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 · 2020-09-13T18:52:48Z

@thalieht

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.

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 :)

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.

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:

...
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:

(...) --lock
...

Second Phase

...
After 10-15 days, the marked ones will be rechecked. If no activity was present they will be autoclosed and locked

(emphasis mine)

I'll see if i can find the duplicates.

I see you've resolved more than half of them already, great job 👍

FranciscoPombal · 2020-09-13T19:06:30Z

@xavier2k6

One of the things that is much needed as well is the issue template rework: #12574.

#11161 seems to have been abandoned?!

#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.

I think we need a new labeling/triaging/priority system.

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.

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 · 2020-09-13T19:10:48Z

**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 · 2020-09-13T19:15:20Z

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

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 · 2020-09-13T19:29:31Z

@xavier2k6

**Issues related to OP "user accounts" that have been deleted by github/now represented by "ghost"

what should be done with these? (x60)

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.

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....

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 · 2020-09-13T19:41:20Z

@xavier2k6

**Issues related to OP "user accounts" that have been deleted by github/now represented by "ghost"
what should be done with these? (x60)

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.

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+F for ghost as searching with author:ghost doesn't relinquish any results, just as a heads-up/bare in mind.

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....

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.

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 · 2020-09-14T00:59:05Z

@xavier2k6

**Issues related to OP "user accounts" that have been deleted by github/now represented by "ghost"

what should be done with these? (x60)

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 · 2020-09-14T18:47:24Z

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 · 2020-09-14T19:26:44Z

@xavier2k6

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.

30 remaining.

xavier2k6 · 2020-09-30T20:14:29Z

planning to do a status update at wknd 02-04 OCT (time permitting.)

FranciscoPombal · 2020-10-01T11:10:08Z

@xavier2k6

planning to do a status update at wknd 02-04 OCT (time permitting.)

What do you mean? Can you please elaborate about what you are working on?

xavier2k6 · 2020-10-01T11:28:40Z

@xavier2k6

planning to do a status update at wknd 02-04 OCT (time permitting.)

What do you mean? Can you please elaborate about what you are working on?

updating of this: #12679 (comment) this: #12679 (comment) & this: #12679 (comment) with latest figures etc.

xavier2k6 · 2020-10-12T20:05:24Z

updated #12679 (comment) & #12679 (comment) with latest figures but didn't update #12679 (comment) 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 · 2020-10-16T16:04:42Z

Tuesday December 3rd 2019 - qBittorrent v4.2.0 release

WINDOWS: Drop support for < Windows 7

Windows XP 5.1.2600

#7531 #9665

Below may need a follow up though...... because of #11399 (comment) & #11399 (comment)
#11399

FranciscoPombal · 2020-10-16T16:45:22Z

@xavier2k6

WINDOWS: Drop support for < Windows 7

~~Typo? It should be Windows XP, right?~~ #12679 (comment)

xavier2k6 · 2020-10-16T17:12:55Z

@xavier2k6

WINDOWS: Drop support for < Windows 7

Typo? It should be Windows XP, right?

It's a snippet of 4.2.0 Release History from official website

FranciscoPombal · 2020-10-16T17:29:40Z

@xavier2k6

It's a snippet of 4.2.0 Release History from official website

~~Right, it's wrong... Feel free to submit a PR fixing that both here in the changelog as well as the website.~~ #12679 (comment)

xavier2k6 · 2020-10-16T17:35:38Z

Right, it's wrong

How so? (Am I missing something obvious here?)

Drop support for < Windows 7

Doesn't that signify support for windows versions less than 7 are no longer supported so that means windows Vista too but I just haven't looked for issues of that build yet...

FranciscoPombal · 2020-10-16T17:40:40Z

@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 · 2020-10-16T17:41:18Z

windows vista
#8878

#547 doesn't seem to be longer relevant/close?

jagannatharjun · 2020-10-18T14:47:53Z

why not https://github.com/marketplace/stale ?

xavier2k6 · 2020-10-18T15:10:28Z

why not https://github.com/marketplace/stale ?

#11924

Edit: similar #11363

xavier2k6 · 2020-10-23T11:30:24Z

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 #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.x

If 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:

991 x "Open Issues"
524 x Unlabelled


Build system	4	Code cleanup	7	Confirmed bug	10
Core	6	Crash	49	Data loss	3
Discussion	2	Documentation	4	Feature	1
GUI	106	Libtorrent	3	Look and Feel	24
Meta	3	Network	31	OS: Linux	23
OS: macOS	19	OS: Windows	15	Performance	44
Project management	6	Proxy/VPN	2	Qt bugs	5
RSS	51	Search engine	8	Temp folder	27
Translation	2	WebAPI	18	WebUI	29

NOTE:

(Some Issues may have more than 1 designated Issue Tracker label assigned)

FranciscoPombal · 2020-10-23T12:00:59Z

@xavier2k6 I took care of the 6 "Invalid + Not an issue" issues and edited you post accordingly.

xavier2k6 · 2020-10-23T16:55:42Z

Updated #12679 (comment) with new info/removed closed/taken care of, thanks @FranciscoPombal & general clean-up/aesthetics

sledgehammer999 · 2020-10-29T21:39:28Z

I have updated the tool and run it. It seems to have closed 594 old issues.

FranciscoPombal · 2020-10-29T22:00:31Z

@sledgehammer999

I have updated the tool and run it. It seems to have closed 594 old issues.

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.x or 4.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 · 2020-10-29T22:19:11Z

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 · 2020-10-29T22:22:57Z

@FranciscoPombal don't reopen this issue. It's purpose is done.

xavier2k6 · 2020-10-29T22:23:54Z

@sledgehammer999 @FranciscoPombal please review #12679 (comment) again as (although not currently updated due to running of tool) 557 could be closed.....

xavier2k6 · 2020-11-30T16:20:24Z

@sledgehammer999 The label:autoCloseOldIssue is 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:autoCloseOldIssue approx 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 · 2020-12-17T14:23:04Z

@FranciscoPombal Could you take a look at #12679 (comment) 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 · 2020-12-17T15:13:38Z

@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:open filter, I think I've now fixed all instances of that.

xavier2k6 · 2020-12-17T16:25:26Z

@FranciscoPombal Thanks, seem to be fixed now alright from what I've checked.

I think the scripts didn't take in to account the ghost accounts & the parameters will have to be changed the next time the tool/script is used as updated is practically useless now over the whole bounty initiative....

Will have to use something like e.g. created:<=2020-04-26T00:00:00Z (day after 4.2.5 release)

xavier2k6 · 2023-07-19T20:09:20Z

@sledgehammer999 Do you plan to do another run of this batch tool in the near future?

sledgehammer999 added Meta Project management labels Apr 27, 2020

sledgehammer999 mentioned this issue Apr 27, 2020

Automated batch amending of issue titles based on label and regex #12101

Closed

Ryrynz mentioned this issue Apr 29, 2020

UPnP error message at every qbittorrent start #512

Closed

xavier2k6 mentioned this issue Aug 4, 2020

Review for the potential of using "Issue Label Bot" to Auto Label for qBittorrent Issues Tracker #11363

Closed

This was referenced Sep 13, 2020

Closing old bugs / issues #9511

Closed

Mismanagement of the Github issue tracker #11175

Closed

sledgehammer999 closed this as completed Oct 29, 2020

FranciscoPombal reopened this Oct 29, 2020

sledgehammer999 closed this as completed Oct 29, 2020

qbittorrent locked and limited conversation to collaborators Mar 1, 2021

[Tool] Batch close old issues #12679

[Tool] Batch close old issues #12679

Comments

sledgehammer999 commented Apr 27, 2020

Second Phase

sledgehammer999 commented Apr 28, 2020

ghost commented Apr 28, 2020

FranciscoPombal commented Apr 28, 2020 • edited Loading

FranciscoPombal commented Apr 28, 2020 • edited Loading

FranciscoPombal commented Apr 29, 2020

xavier2k6 commented Sep 12, 2020 • edited Loading

Breakdown of "Labelled Issues Only" with "Open" status

Applicable to 45x qBittorrent Issue Tracker Labels

Saturday, Sep 12, 2020 16:50 GMT Monday, Oct 12, 2020 21:00 GMT

(Date/data will change periodically when updated)

NOTE:

xavier2k6 commented Sep 12, 2020 • edited Loading

Breakdown of "Labelled Issues Only" (Without "Feature request" label applied)

Saturday, Sep 12, 2020 16:50 GMT Monday, Oct 12, 2020 21:00 GMT

(Date/data will change periodically when updated)

NOTE:

xavier2k6 commented Sep 12, 2020 • edited Loading

Current "Open Issues" status of qBittorrent Issue Tracker

ISSUES

Pinned

Linked with Pull Requests

Assigned to milestones

Assigned to Team Member

Could be potentially closed

Unlabelled

Action Plan

thalieht commented Sep 12, 2020

xavier2k6 commented Sep 12, 2020 • edited Loading

FranciscoPombal commented Sep 13, 2020

FranciscoPombal commented Sep 13, 2020

xavier2k6 commented Sep 13, 2020 • edited Loading

thalieht commented Sep 13, 2020

FranciscoPombal commented Sep 13, 2020

Second Phase

FranciscoPombal commented Sep 13, 2020 • edited Loading

xavier2k6 commented Sep 13, 2020 • edited Loading

xavier2k6 commented Sep 13, 2020

FranciscoPombal commented Sep 13, 2020

xavier2k6 commented Sep 13, 2020 • edited Loading

FranciscoPombal commented Sep 14, 2020 • edited Loading

xavier2k6 commented Sep 14, 2020

FranciscoPombal commented Sep 14, 2020

xavier2k6 commented Sep 30, 2020

FranciscoPombal commented Oct 1, 2020

xavier2k6 commented Oct 1, 2020 • edited Loading

xavier2k6 commented Oct 12, 2020 • edited Loading

xavier2k6 commented Oct 16, 2020 • edited Loading

Tuesday December 3rd 2019 - qBittorrent v4.2.0 release

FranciscoPombal commented Oct 16, 2020 • edited Loading

xavier2k6 commented Oct 16, 2020

FranciscoPombal commented Oct 16, 2020 • edited Loading

xavier2k6 commented Oct 16, 2020 • edited Loading

FranciscoPombal commented Oct 16, 2020

xavier2k6 commented Oct 16, 2020 • edited Loading

jagannatharjun commented Oct 18, 2020

xavier2k6 commented Oct 18, 2020 • edited Loading

xavier2k6 commented Oct 23, 2020 • edited Loading

qBittorrent v4.3.0 Released (Sunday October 18th 2020 )

NOTE:

FranciscoPombal commented Oct 23, 2020

xavier2k6 commented Oct 23, 2020

sledgehammer999 commented Oct 29, 2020

FranciscoPombal commented Oct 29, 2020

sledgehammer999 commented Oct 29, 2020 • edited Loading

sledgehammer999 commented Oct 29, 2020

xavier2k6 commented Oct 29, 2020 • edited Loading

xavier2k6 commented Nov 30, 2020 • edited Loading

xavier2k6 commented Dec 17, 2020

FranciscoPombal commented Dec 17, 2020

xavier2k6 commented Dec 17, 2020

xavier2k6 commented Jul 19, 2023

FranciscoPombal commented Apr 28, 2020 •

edited

Loading

FranciscoPombal commented Apr 28, 2020 •

edited

Loading

xavier2k6 commented Sep 12, 2020 •

edited

Loading

xavier2k6 commented Sep 12, 2020 •

edited

Loading

xavier2k6 commented Sep 12, 2020 •

edited

Loading

xavier2k6 commented Sep 12, 2020 •

edited

Loading

xavier2k6 commented Sep 13, 2020 •

edited

Loading

FranciscoPombal commented Sep 13, 2020 •

edited

Loading

xavier2k6 commented Sep 13, 2020 •

edited

Loading

xavier2k6 commented Sep 13, 2020 •

edited

Loading

FranciscoPombal commented Sep 14, 2020 •

edited

Loading

xavier2k6 commented Oct 1, 2020 •

edited

Loading

xavier2k6 commented Oct 12, 2020 •

edited

Loading

xavier2k6 commented Oct 16, 2020 •

edited

Loading

FranciscoPombal commented Oct 16, 2020 •

edited

Loading

FranciscoPombal commented Oct 16, 2020 •

edited

Loading

xavier2k6 commented Oct 16, 2020 •

edited

Loading

xavier2k6 commented Oct 16, 2020 •

edited

Loading

xavier2k6 commented Oct 18, 2020 •

edited

Loading

xavier2k6 commented Oct 23, 2020 •

edited

Loading

sledgehammer999 commented Oct 29, 2020 •

edited

Loading

xavier2k6 commented Oct 29, 2020 •

edited

Loading

xavier2k6 commented Nov 30, 2020 •

edited

Loading