- wine-gitlab - winehq.org

[PATCH v4 0/1] MR211: vkd3d-shader/hlsl: Support clip() intrinsic.
by Nikolay Sivov (＠nsivov) 01 Jun '23

01 Jun '23

-- v4: vkd3d-shader/hlsl: Support clip() intrinsic. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/211

4 9

Re: [PATCH v2 0/1] MR2951: msvcr100: Fix next writer unblocking in reader_writer_lock::unlock. - approved
by Alexandre Julliard (＠julliard) 01 Jun '23

01 Jun '23

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2951

1 0

Re: [PATCH v2 0/3] MR2895: Get rid of some casts to self. - approved
by Alexandre Julliard (＠julliard) 01 Jun '23

01 Jun '23

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2895

1 0

Re: [PATCH v2 0/1] MR2933: kernelbase: Don't modify non-volatile regs in RaiseException() on x64. - approved
by Alexandre Julliard (＠julliard) 01 Jun '23

01 Jun '23

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2933

1 0

Re: [PATCH v3 0/2] MR2948: Xact fixes - approved
by Alexandre Julliard (＠julliard) 01 Jun '23

01 Jun '23

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2948

1 0

Re: [PATCH v2 0/1] MR2947: krnl386.exe16: Don't overflow when calculating size - approved
by Alexandre Julliard (＠julliard) 01 Jun '23

01 Jun '23

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2947

1 0

Re: [PATCH v2 0/1] MR2945: po: Update Lithuanian translation. - approved
by Alexandre Julliard (＠julliard) 01 Jun '23

01 Jun '23

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2945

1 0

Re: [PATCH v2 0/5] MR2901: winegstreamer: Test and fix H264 timestamps and concatenated streams.
by Rémi Bernon (＠rbernon) 01 Jun '23

01 Jun '23

On Thu Jun 1 17:15:46 2023 +0000, Zebediah Figura wrote: > > 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. It is not a matter of no-confidence, although I could argue that being told that my statements are non-sensical in several occasions isn't a great way to build confidence. Perhaps a matter of diverging opinions, but moreover it is a matter of trying hard to keep downstream from diverging. I took maintainership of the wg_transform code, not just because I wrote most of it, but also in order to help with the bandwidth, and avoid bothering two persons on every single change. I believe I have taken every comment into account very carefully, and haven't bypassed your review or Nikolay's for MF related things, on any meaningful change. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2901#note_34369

1 0

[PATCH 0/1] MR2951: msvcr100: Fix next writer unblocking in reader_writer_lock::unlock.
by Piotr Caban (＠piotr) 01 Jun '23

01 Jun '23

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/2951

2 1

Re: [PATCH v2 0/5] MR2901: winegstreamer: Test and fix H264 timestamps and concatenated streams.
by Zebediah Figura (＠zfigura) 01 Jun '23

01 Jun '23

> 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

1 0

2025

2024

2023

2022

wine-gitlab