> Well I don't know that, it's been mostly a week without any activity and it's not the first time winegstreamer MR have been left unnoticed. I have been upstreaming winegstreamer patches for a big part of last year and the slow iteration have been making it very difficult. We have patches piling up in Proton once again, and diverging implementations already. I would very much like to avoid getting in the same situation as we've been.
It had been six days, which is nominally a bit slow, but the slowness was largely due to (a) multiple winegstreamer patches from you in that time [and while I appreciate smaller patch series, that doesn't mean that I'm going to review three patch series all in the same day], (b) the weekend, (c) a US holiday during which I wasn't doing any work, and (d) patch 5/5 which does multiple things at once and was therefore hard to read.
> I don't think these changes present any risk, they have been thoroughly tested, by Paul and I, but also with a lot of Wine tests, and the changes have been in Proton for a long while already. I also maintain wg_transform and their client, so, although I'm happy to take constructive comments, I'm ultimately going to be responsible for the changes.
As I've stated when the issue of maintainership was brought up last, I still would very much like to be consulted on winegstreamer changes. Whether they have been tested or not, I find that winegstreamer code has been getting increasingly complex and difficult to maintain, in ways that are fixable and in ways that aren't, and I see things that can be improved in many incoming winegstreamer patches.
If you want to call for no-confidence in my maintainership, fine, but please let's be clear about that and not abuse gitlab.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2901#note_34367
On Thu Jun 1 16:21:55 2023 +0000, Zebediah Figura wrote:
> > Rémi Bernon removed review request for @zfigura May 31, 2023, 10:57 AM
> Please don't do that.
> In this case it's fine since I've reviewed the patch and was going to
> sign off on it anyway.
Well I don't know that, it's been mostly a week without any activity and it's not the first time winegstreamer MR have been left unnoticed. I have been upstreaming winegstreamer patches for a big part of last year and the slow iteration have been making it very difficult. We have patches piling up in Proton once again, and diverging implementations already. I would very much like to avoid getting in the same situation as we've been.
I don't think these changes present any risk, they have been thoroughly tested, by Paul and I, but also with a lot of Wine tests, and the changes have been in Proton for a long while already. I also maintain wg_transform and their client, so, although I'm happy to take constructive comments, I'm ultimately going to be responsible for the changes.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2901#note_34365
The application again the bug, passed 1 as the elem parameter which
doubled the memory being allocated. When it overflowed (became negative),
the value was passed into GlobalAlloc16 which then failed.
GlobalAlloc16 takes a DWORD parameter, so the value isn't going to be truncated.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53092
Original patch by github user cracyc for winevdm.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2947
To be merged after !2907.
--
v2: wineoss: Use mmdevapi's AudioClient's GetService.
winecoreaudio: Use mmdevapi's AudioClient's GetService.
winealsa: Use mmdevapi's AudioClient's GetService.
winepulse: Move AudioClient's GetService into mmdevapi.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2908