10:43 MrCooper: Venemo: assuming those kernel crashes didn't happen with F37, can you try bisecting between 6.1 & 6.2?
10:44 Venemo: MrCooper: it takes a couple of hours of random use to reproduce it, so I don't think it is bisectable
10:44 MrCooper: I've bisected worse issues in that regard :/
10:45 MrCooper: you can take a few days before you declare a commit good
10:46 MrCooper: I think you're more likely to get traction on it like this than hoping the DC developers pick up on it, but it's up to you
10:48 Venemo: I don't like the attitude of pushing the responsibility of investigating regressions on the user
10:49 Venemo: in this case I think a bisect is probably too slow
10:50 Venemo: taking a few days per commit would mean a bisect that takes a month? do you honestly think that is reasonable?
14:12 MrCooper: Venemo: I don't disagree, just getting progress in a month is still better than never
14:19 Venemo: MrCooper: problem is that whatever is in between 6.1.x and 6.2.y is likely not generally usable and contains other regressions as well
14:20 MrCooper: true; it is possible to bisect only the DRM changes, but it's more complicated and manual
14:21 Venemo: also, in a month they will likely fix this one and regress something else anyway
17:37 _ds_: Re. slow bisections – I suspect that what you want is many people who see the problem doing the bisection in a (somehow) co-ordinated way. It won't help with the good commits, but it should mean a better chance of finding the bad commits more quickly.