Not a trivial update this time, two extensions are blocked by a Vulkan xml bug.
--
v2: winevulkan: Update to VK spec version 1.3.213.
winevulkan: Prevent infinite recursion in make_vulkan.
https://gitlab.winehq.org/wine/wine/-/merge_requests/57
--
v2: mf/tests: Update a broken IMFMediaSink_AddStreamSink result check.
mf/tests: Tweak topology loader tests results based on the video processor presence.
winegstreamer: Register the video processor transform.
winegstreamer: Move MFT registration list out of static scope.
https://gitlab.winehq.org/wine/wine/-/merge_requests/41
From: Angelo Haller <angelo(a)szanni.org>
The following patches fix sending of the LVN_ODSTATECHANGED notification for
LVS_OWNERDATA list views, adding more refined tests in the process and
fixing various bugs.
Warning: I have had access to the Windows Research Kernel (WRK) 1.2
~10 years ago. These changes are regarding comctrl32 & tests which are NOT
part of the WRK. As outlined in https://wiki.winehq.org/Developer_FAQ this
should therefore satisfy the requirement of ONLY …
[View More]submitting patches to
components I have NOT had access to.
Angelo Haller (6):
comctl32/tests: Expand ownerdata listview tests.
comctl32/listview: Move LVN_ODSTATECHANGED notification to function.
comctl32/listview: Send LVN_ODSTATECHANGED only for virtual lists.
comctl32/listview: Send LVN_ODSTATECHANGED notification.
comctl32/listview: Send LVN_ODSTATECHANGED only for true ranges.
comctl32/listview: Fix deselect on LVS_OWNERDATA.
dlls/comctl32/listview.c | 71 ++++++++++++++++++++++++++--------
dlls/comctl32/tests/listview.c | 59 ++++++++++++++++++++++++----
2 files changed, 105 insertions(+), 25 deletions(-)
Signed-off-by: Angelo Haller <angelo(a)szanni.org>
--
2.36.0
[View Less]
--
v2: ntdll: Split RtlSizeHeap to a separate heap_size helper.
ntdll: Split RtlReAllocateHeap to a separate heap_reallocate helper.
ntdll: Split RtlFreeHeap to a separate heap_free helper.
ntdll: Split RtlAllocateHeap to a separate heap_allocate helper.
ntdll: Split HEAP_IsRealArena to heap_validate and heap_validate_ptr.
ntdll: Lock heap critical section outside of HEAP_IsRealArena.
https://gitlab.winehq.org/wine/wine/-/merge_requests/55
Folks,
Here's a description of the envisioned workflow for using Gitlab as the
primary platform for Wine development, should we decide to adopt it.
This will probably evolve as we experiment and find out what
works or doesn't work for us. All feedback/suggestions are welcome.
1. All patch series are submitted as Merge Requests, so that the
proper information can be captured. The usual rules apply (small
patches, small number of patches per MR, sign-off by submitter).
There …
[View More]are various methods available for creating merge requests:
- using the web interface
- directly when pushing: git push -o merge_request.create
cf. https://docs.gitlab.com/ee/user/project/push_options.html
- from the command line, eg. 'glab mr create'
cf. https://glab.readthedocs.io/en/latest/mr/create.html
- by email
cf. https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_reque…
2. The merge request will run through the CI pipeline, ideally
including a testbot run (not implemented yet).
3. The patches of the merge request will be forwarded to wine-devel
by the mail gateway, for people who prefer to use their existing
email tools to manage patches.
4. Reviewers will be automatically assigned to the merge request
based on the MAINTAINERS file (not implemented yet). Reviewers
can also be assigned manually. People assigned as reviewers
should receive a notification from gitlab.
5. When someone starts reviewing a patch, they can optionally assign
the patch to themselves, so that the submitter is aware that
someone is working on their patch.
6. Feedback on patches can be sent by replying to the wine-devel
email, or by adding a comment on gitlab. The mail gateway will
bridge things so that all comments are reflected both on gitlab
and on wine-devel.
Note: if you subscribe to gitlab notifications (recommended)
currently you'll get many duplicate emails. There are mail
headers that can be used for filtering, but we may want to
handle this differently, suggestions are welcome.
7. If there are comments, the submitter can address them and update
the merge request by pushing to the MR branch. The mail gateway
will send the new version of the patches to wine-devel (except
for trivial changes) for further review.
8. Once a reviewer approves a merge request, they should mark it
approved in gitlab. The idea is that this will replace the
existing "send a signoff by email" mechanism. Note that an
approval applies to the whole merge request, not to individual
patches. This should be one more reason to keep patch series
small.
Approvals can be sent by:
- using the approve button on the web interface
- replying to a gitlab notification with "/approve"
(note: replying to a wine-devel mail won't work, it needs the
magic gitlab headers)
cf. https://docs.gitlab.com/ee/user/project/quick_actions.html
- from the command line, eg. 'glab mr approve'
cf. https://glab.readthedocs.io/en/latest/mr/approve.html
9. Once a merge request has been approved by all reviewers, I'll
merge it into my tree, do a full testbot run to make sure it
doesn't break anything, then push the results and mark the merge
request as 'merged'.
10. If a merge request is no longer relevant, the submitter should
close it. We may want to add an auto-close process for stale
merge requests at some point.
--
Alexandre Julliard
julliard(a)winehq.org
[View Less]