[Suggestion] Set-up automatic closing of stale issues (or something similar) - there are too many open issues that date back from 4 years ago

[kwand]

I've been meaning to comment on this a few years ago, but I think it's appropriate to say something about it now - given that there are still pages of open issues dating back from 2019, 2018 (some of which I know for a fact are outdated or have been addressed).

Now, I recognize the response time to latest issues have not been the best lately (given there are still tons of issues from the last 6 months with no replies yet), so perhaps the staleness "countdown" can be set rather high. Of course, issues can always be re-opened if they were wrongly automatically closed.

But I fail to see why many issues dating from beyond the last two years should be kept open - given that many of the ones I've examined seem to no longer apply on the latest branch.

(I would not mind helping to provide a list that should be closed manually - but I believe adding automatic closing is worthwhile)

[yshui]

Hi, i would appreciate it if you can point out some outdated issues, thanks. As for auto-closing, for personal experiences I don't like doing that.

[kwand]

@yshui Apologies for the late reply - been quite busy and forgot that I even opened this.

I can provide you with a list of issues that I believe should most definitely be revisited and seriously considered for closure from the last and second pages (i.e. page 9/10 as it is today; not sure when you will see this).

• Shadow on bars #4, already addressed by Add clip-shadow-above configuration and wintype option #656 (which also names --shadow-exclude-reg produces deprecation warning, but the suggested replacement can't do the same thing #494 as an addressed issue that should be closed, but was not)
• (Noticeable lag when opening/closing windows #11, no update in 3 years. Does this issue still exist? I'm unable to replicate it)
• --sw-opti is broken when used together with --benchmark #12, --sw-opti was deprecated with 51da5d3
• Kawase blur #32, already implemented?
• Discussion of technical config settings #37, no update in 3 years and requests to add --vsync-use-glfinish flag as default, but this no longer exists.
• Very bad performance and lag in VirtualBox #40, no update in 3 years, unknown if still exists on latest codebase
• Excluding transparent autoscroll cursor in Firefox automatically? #54, no update in 3 years and I believe it's discussed in the issue that we do not want to implement this? (Should probably be moved into the discussions section regardless, given the label)
• Tearing when back from sleep/screensaver #55, could not be reproduced then and no update in 3 years
• Fading doesn't affect window decorators. #63, no update in 3 years, appears to have been fixed upstream but no reply after asking for confirmation
• VSync for xrender backend #82, addressed by new backends? Issue doesn't seem to serve a purpose by remaining open
• (Screen freezes when video players are made fullscreen #84, no update in 2 years after OP claimed they are no longer able to reproduce)
• request for wiki or guide or summary of the parameters  #97, should have been moved to discussions
• Would it be possible to utilize freesync/gsync/vrr to further optimize compton? #126, should have been moved to discussions (Also, I gave this idea a try almost a year ago. Possibly a terrible idea as the shifts between min and max refresh rate is quite noticeable - and I'm not talking about flickering, which can be a problem with certain VRR monitors as mentioned in the issue. I believe there are other reasons that convinced me to not investigate this further - though I do remember that on Windows, activating VRR with the full desktop causes certain apps to behave like a stuttery mess. Probably more trouble than it's worth to implement this)
• Terrible latency with compton v6 compared to v5.1 on AMD #139, no update in 3 years, possibly no longer exists on current codebase
• Improve frame timing (a.k.a. reduce input lag) #147, I believe this is addressed in the new backends?
• shadow = true causes performance issues when dragging Chromium windows #151, no update in 3 years, and I cannot reproduce on the current codebase + latest Chromium (or Chrome)
• 25% cpu and slow screen writing after suspend, when using -b option #153, could not be reproduced then and no update in 3 years
• Some windows are not displayed after reloading i3 #166, no update in 3 years
• Excluding focus on a specific window (dictionary text-translating pop-up)? #167, OP agreed with your request to close (but was never closed)
• Huge lags caused by xrender backend #174, no update in 3 years, possibly no longer exists on the new codebase?
• (Weird screen update artifacts under mouse cursor with DisplayLink #192, no update in 3 years, though another user replied (in 2021) offering a solution (disabling vsync))
• High temperature with electron apps #193, no update in 3 years. Seems to have been caused by not using use-damage, which caused high CPU usage + high temps. (OP claimed overall CPU usage was low, but noticed spikes of 40-50% which they claim could not have caused the high temperatures. I disagree as I've noticed similar temperatures with intermittent spikes on my laptops, though we are lacking further information from the OP in this case. Then again, there's been no update from them in 3 years)
• Chromium under opaque windows does not rerender #200, no update in 3 years. I cannot reproduce this with Chromium or Firefox (as recently reported in 2020). Possibly this issue no longer exists in the latest codebase?
• [i3wm + compton] Background image flash on opening new window #202, no update in 3 years. Reported that the new backends fix this.
• (new GLX backend: stutter when snapping windows and on button press in Chromium #208 , no update in 3 years. Appears to have been mostly resolved?)

Hopefully, you'll agree with me that there are more than a handful open issues that should no longer remain open among the 236 that exist today. I can confirm that it is not just pages 9/10 that have these kinds of open issues - I went through more pages than 9/10 prior to opening this issue, but unfortunately, I no longer remember the exact issues from the other pages + currently do not have the time to go through more.

While I do prefer manual inspection to an automated system, in the absence of someone dedicated to going through these older issues and closing them, an automated system I believe is not a bad option to consider - especially when one can customize how strict/relaxed the system could be.

[tryone144]

Thanks for looking into some of these ancient issues. I've closed some that are (almost) certainly no longer relevant.

However, I am not too sure on how to handle the "performance" issues. These seem to be hard to reproduce and are most likely no longer relevant given the huge changes in the backends over the last years.

We could tag these issues as stale and close them after some (negotiable) time has passed.

I think the biggest problem as of now is that there are multiple issues that are most likely duplicates — or at least very similar — but cannot be easily found via the search. This is in part caused by the inclusion of the complete (sample) config in each issue, which makes searching for a specific option impossible.

[masaeedu]

@kwand I think these issues should go through at least the "is it still stale" -> "no response within x duration" -> "close" workflow. At least one of the issues you've selected in your list still affects me today (#200)

[yshui]

@masaeedu unfortunately #200 is a design decision on chromium's side, so there's nothing picom can do. i suggest you report an issue to them.

[yshui]

ok i've been procrastinating long enough, let's close some of these issues.

@kwand thanks again for find them.

as for auto-closing, if there is a bot poking me every couple months asking me to write some nonsensical replies to keep an issue alive, i'd be pretty annoyed. that's why i don't like doing it.

[yshui]

So I thought about this. Although I don't think we should do auto-closing in general, there is still some automation we can do:

1. auto label stale issues, making them easy to find. and then we can periodically go through them and decide whether to close them. scrap this one, you can search for issues like this on github easily: is:issue is:open updated:<2020-01-01
2. delayed close. for example after an issue is fixed and waiting for user confirmation, i should be able to mark the issue for delayed close if the reporter doesn't respond for a long time.

Does anyone know if there is tooling that can do these?