On 23/10/2023 18:58, Rémi Bernon wrote:
You started filing bugs for new test failures, as regressions (and I got more than a few myself). I think this could be a good incentive, but as it's mixed with code regressions it is also biases toward fixing them during the code freeze. This might be alright but it also means it will take a long time before some are fixed.
Also I'm not completely sure the regression list rank is very effective, as I see it, it only means: small regressions are okay, though please fix them once a year.
I think this is the wrong approach. I personally take regressions very seriously, and as a priority if it's something I screwed up.
Regressions can be pretty serious (unless it's some flaky test I guess), I think they should *always* be prioritized, not just deferred to code freeze, test failures or not.
It's not just for the end users who have to suffer with the regression or have to revert the blamed commit if they want to keep updating Wine. It's also for you, because usually the faster you get to the regression, the better your mind is set to that code (assuming it was filed relatively recently after it's been broken), so you have better idea at that point how it works, and maybe why it got broken, than several months later down the line.
And also it's important indirectly for users to update (or downstream) so they can report regressions earlier than once a year. Otherwise too much gets piled up. And I know some people are scared to update because of regressions and "developers" not taking the time to fix them after breaking it, so they have reports sitting for months, which is extremely frustrating (and well, developers can be users too, maybe not in the same area/module of what was broken though).