http://bugs.winehq.org/show_bug.cgi?id=55775 --- Comment #43 from Stian Low <wineryyyyy@gmail.com> --- (In reply to Zeb Figura from comment #41)
I apologize, I seem to have misread the intent behind your message. I should have been more gracious.
No worries. I've seen how badly other reporters misbehave sometimes so I can see how my bluntness may have triggered association with them.
No, it's broadly true; the phrasing seemed more accusatory (i.e. that lagging behind is intentional, rather than a consequence of CW's choices to prioritize other work) but I gather this was unintentional.
Thanks again for clarifying. I was not implying it would necessarily be a bad thing if the lag was intentional to give Steam an edge during partnerships. If that's not the case then I'll consider my efforts more worthwhile and not in conflict with a strategy unknown to me.
To be clear, when I say they are lower priority I don't mean that they are *low* priority. I would rate shared resources as the #2 priority, after "finish Damavand", and I'm not even sure that's right. Also to clarify, that's just priorities as in "what I personally work on". Review of someone else's patches is always the highest priority. I know it doesn't seem that way, and I apologize; I really don't want to be as slow with review as I am.
I know folks are busy and not all reviews are the same. MR-11398 review is more trivial and comes down to a simple decision. MR-10567 is far less trivial (and vital to finish Damavand) and I've let reviewers know I understand that more thorough review may take more time: - https://gitlab.winehq.org/wine/wine/-/merge_requests/10567#note_146816
I'm sorry you feel that your fixes are being automatically rejected; that's
Only MR-11398 seemed like an automatic rejection.
The only patch I've considered rejecting is 11398, because (1) it doesn't actually encourage anyone to fix the bug properly; in fact it reduces the incentive; (2) it's rather indirect for a workaround, compared to other workarounds we have in d3d; (3) it's not clear to me it's going to be that hard. But I also see the point of fixing a larger class of applications now, and it's simple enough too, so it's hard to decide.
I agree it may reduce incentive to fix the bug but that would imply because its considered at least partially fixed. I intend to fix the other bug via MR-11404 regardless which has its own more edge use cases that MR-11398 does not fix but helps clarify. MR-11398 would enable replies to reporters to simply test if videos are fixed via `WINE_D3D_CONFIG=no_create_flags=0x800` and if so then it clarifies the problem. Otherwise bugs become clouded with the rest of the sea of related/duplicate bugs. MR-11398 may give some folks incentive to use wine video workarounds vs DXVK until D3D flag is no longer required to force it anymore via MR-11404. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.