Closed sledgehammer999 closed 3 years ago
sledgehammer999
commented
4 years ago 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
4 years ago 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
4 years ago @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
4 years ago @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 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
4 years ago @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
commented
4 years ago | 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 |
(Some Issues may have more than 1 designated Issue Tracker label assigned)
xavier2k6
commented
4 years ago | 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 |
(Some Issues may have more than 1 designated Issue Tracker label assigned) Feature request (Only) has no other label applied.
xavier2k6
commented
4 years ago (Date/data will change periodically when updated) Saturday, Sep 12, 2020 16:50 GMT
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)
3
11 to milestone v3.2.1 3 to milestone v3.3.10 1 to milestone 4.1.10 3 to milestone 4.2.6
12 to FranciscoPombal 13 to glassez 3 to zeule 2 to Piccirello
704 --cutoff-timepoint=2019-05-06T00:00:00Z --skip-label="Feature request"
779 remain Unlabelled across 32 pages (1 page = 25 issues)
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
4 years ago 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).
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
commented
4 years ago 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 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 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".
24 Nov 2015 but won't see full libtorrent implementation/support until 2.x or possibly 3.x reference: https://github.com/arvidn/libtorrent/pull/4123#issuecomment-676064126 & https://github.com/arvidn/libtorrent/pull/4123#issuecomment-676074545FranciscoPombal
commented
4 years ago @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'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:
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
4 years ago @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
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.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.
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
commented
4 years ago @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
commented
4 years ago @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 :+1:
FranciscoPombal
commented
4 years ago @xavier2k6
One of the things that is much needed as well is the issue template rework: #12574.
11161 seems to have been abandoned?!
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.
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
commented
4 years ago Issues related to OP "user accounts" that have been deleted by github/now represented by "ghost"**
what should be done with these? (x60)
xavier2k6
commented
4 years ago 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
commented
4 years ago @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
commented
4 years ago @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
commented
4 years ago @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:
There's a few of these I might close still, depending on whether I can reproduce them tomorrow.
xavier2k6
commented
4 years ago 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.
FranciscoPombal
commented
4 years ago @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.
ghost
commented
4 years ago 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
4 years ago @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
4 years ago planning to do a status update at wknd 02-04 OCT (time permitting.)
FranciscoPombal
commented
4 years ago @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
commented
4 years ago @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: 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
4 years ago 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
4 years ago Windows 7Below 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
FranciscoPombal
commented
4 years ago @xavier2k6
WINDOWS: Drop support for < Windows 7
~Typo? It should be Windows XP, right?~ https://github.com/qbittorrent/qBittorrent/issues/12679#issuecomment-710292894
xavier2k6
commented
4 years ago @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
commented
4 years ago @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.~ https://github.com/qbittorrent/qBittorrent/issues/12679#issuecomment-710292894
xavier2k6
commented
4 years ago 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
commented
4 years ago @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
4 years ago windows vista
jagannatharjun
commented
4 years ago why not https://github.com/marketplace/stale ?
xavier2k6
commented
4 years ago xavier2k6
commented
4 years ago 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.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 |
(Some Issues may have more than 1 designated Issue Tracker label assigned)
FranciscoPombal
commented
4 years ago @xavier2k6 I took care of the 6 "Invalid + Not an issue" issues and edited you post accordingly.
xavier2k6
commented
3 years ago 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
3 years ago I have updated the tool and run it. It seems to have closed 594 old issues.
FranciscoPombal
commented
3 years ago @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 :+1:.
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
commented
3 years ago 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
3 years ago @FranciscoPombal don't reopen this issue. It's purpose is done.
xavier2k6
commented
3 years ago @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
3 years ago @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
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)
Does the labelling system need to be amended??
Here are the ones, that seem to show up:
xavier2k6
commented
3 years ago @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
3 years ago @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:
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
commented
3 years ago @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)
@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?