Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 9.0 (505 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * None Added: * None Updated: * vkd3d-latest Where can you help * Run Steam/Battle.net/GOG/UPlay/Epic * Test your favorite game. * Test your favorite applications. * Improve staging patches and get them accepted upstream. * Suggest patches to be included in staging. As always, if you find a bug, please report it via https://bugs.winehq.org Best Regards Alistair.
This release seems okay-ish, but I have some questions: 1. Can you push at least *some* of my attached patches to wine-staging? I'm tired of them being in my local tree/builds and want other people to take advantage of them (especially the reparse point fixes) 2. Why do patches need to be "manually verified" before pushing them to wine-staging? Isn't the GitLab MR system (which is currently used by upstream Wine) good enough for that? 3. Does anyone work on wine-staging other than you and Zeb? I saw Gofman a few times on the repo (so I guess Wine developers have push access too; that Gofman stuff may or may not be pushed by the 2 of you though) 4. Can I become the third wine-staging maintainer? I've been pushing hotfixes for new Wine "commit drops" (this is how I'm calling Julliard's daily commit schedule) in a Discord server for quite a while now and I can fill the GMT+2 gap in the maintainer list (and I might try to resurrect more of the disabled patches; including ones that have been broken by the PE/Unix split) Thanks, Echo/Aida (DodoGTA)
On Friday, 26 January 2024 16:35:16 CST DodoGTA GT wrote:
This release seems okay-ish, but I have some questions: 1. Can you push at least *some* of my attached patches to wine-staging? I'm tired of them being in my local tree/builds and want other people to take advantage of them (especially the reparse point fixes)
Well, you can't exactly complain that we aren't submitting your patches if you don't give them to us ;-) 1/6 and 2/6 are pretty much a waste of time for everyone involved, so I'm not going to bother with them. Compilation warnings can be fixed when patches are rewritten for upstreaming. Wrt 3/6, as I requested before, can you please remove the extraneous noise from the patch set (e.g. moving functions around, changing traces)? It is very difficult to judge whether a patch is doing the right thing when there's all that noise. Wrt 4/6, I don't think it makes sense to remove config options solely because the patches are disabled. Disabling patches is meant to be a temporary measure. 5/6 and 6/6 were rebases that turned out to be more trivial than I feared, and I've pushed them. Note though that 6/6 was incorrect as-is; the line hel_desc.dwDevCaps &= ~(D3DDEVCAPS_HWTRANSFORMANDLIGHT | D3DDEVCAPS_DRAWPRIMITIVES2EX | D3DDEVCAPS_HWRASTERIZATION); was incorrectly dropped. I fixed that to be moved to the appropriate place.
2. Why do patches need to be "manually verified" before pushing them to wine-staging? Isn't the GitLab MR system (which is currently used by upstream Wine) good enough for that?
I don't understand what you mean by this, can you please explain?
3. Does anyone work on wine-staging other than you and Zeb? I saw Gofman a few times on the repo (so I guess Wine developers have push access too; that Gofman stuff may or may not be pushed by the 2 of you though)
The wine-staging team is documented here: https://wiki.winehq.org/Wine-Staging#What_is_Wine_Staging.3F
4. Can I become the third wine-staging maintainer? I've been pushing hotfixes for new Wine "commit drops" (this is how I'm calling Julliard's daily commit schedule) in a Discord server for quite a while now and I can fill the GMT+2 gap in the maintainer list (and I might try to resurrect more of the disabled patches; including ones that have been broken by the PE/Unix split)
Maintaining Wine-Staging is not a trivial matter. In order to do it well you need to understand pretty much every area of Wine, well enough to understand any new patch, be able to affirm that it's not going in the wrong direction, and be able to correctly rebase it. It's not nearly so demanding a job as the maintenance of an upstream branch, but neither is it one that can be done well without that understanding. With respect, I need to see a demonstrated ability to contribute to the Wine project well, and a demonstrated ability to deal with the peculiarities Wine-Staging well, before considering anyone as an additional maintainer. This is not by any means a judgement on you or your ability; rather, as a very new contributor to the project, I simply haven't seen that ability demonstrated one way or the other. I don't know what you mean by "hotfixes", not least because you're publishing them in some non-public place, so I can't really judge from that evidence either. (And there's no need for anyone to cover any gaps in the schedule; nothing we do is urgent.) If you want to help wine-staging—and I'm very glad to hear that—I would like to urge you to please, *upstream wine-staging patches*. It's great to hear you want to resurrect patches, but I'd like to make the additional request that you don't just un-disable them, but rewrite them so that they're suitable for upstream. We need people to lighten the patch load *far* more than we need more people working on rebasing. Not that the latter isn't useful, but in some sense it's a band-aid on the underlying problem that *we have too many patches*. Once we have less patches to rebase, we won't need to spend time rebasing them. Thanks! --Zeb
On 27/01/2024 03:06, Elizabeth Figura wrote:
On Friday, 26 January 2024 16:35:16 CST DodoGTA GT wrote:
This release seems okay-ish, but I have some questions: 1. Can you push at least *some* of my attached patches to wine-staging? I'm tired of them being in my local tree/builds and want other people to take advantage of them (especially the reparse point fixes)
Well, you can't exactly complain that we aren't submitting your patches if you don't give them to us ;-)
1/6 and 2/6 are pretty much a waste of time for everyone involved, so I'm not going to bother with them. Compilation warnings can be fixed when patches are rewritten for upstreaming.
Wrt 3/6, as I requested before, can you please remove the extraneous noise from the patch set (e.g. moving functions around, changing traces)? It is very difficult to judge whether a patch is doing the right thing when there's all that noise.
Wrt 4/6, I don't think it makes sense to remove config options solely because the patches are disabled. Disabling patches is meant to be a temporary measure.
5/6 and 6/6 were rebases that turned out to be more trivial than I feared, and I've pushed them. Note though that 6/6 was incorrect as-is; the line
hel_desc.dwDevCaps &= ~(D3DDEVCAPS_HWTRANSFORMANDLIGHT | D3DDEVCAPS_DRAWPRIMITIVES2EX | D3DDEVCAPS_HWRASTERIZATION);
was incorrectly dropped. I fixed that to be moved to the appropriate place.
2. Why do patches need to be "manually verified" before pushing them to wine-staging? Isn't the GitLab MR system (which is currently used by upstream Wine) good enough for that?
I don't understand what you mean by this, can you please explain?
3. Does anyone work on wine-staging other than you and Zeb? I saw Gofman a few times on the repo (so I guess Wine developers have push access too; that Gofman stuff may or may not be pushed by the 2 of you though)
The wine-staging team is documented here:
https://wiki.winehq.org/Wine-Staging#What_is_Wine_Staging.3F
4. Can I become the third wine-staging maintainer? I've been pushing hotfixes for new Wine "commit drops" (this is how I'm calling Julliard's daily commit schedule) in a Discord server for quite a while now and I can fill the GMT+2 gap in the maintainer list (and I might try to resurrect more of the disabled patches; including ones that have been broken by the PE/Unix split)
Maintaining Wine-Staging is not a trivial matter. In order to do it well you need to understand pretty much every area of Wine, well enough to understand any new patch, be able to affirm that it's not going in the wrong direction, and be able to correctly rebase it. It's not nearly so demanding a job as the maintenance of an upstream branch, but neither is it one that can be done well without that understanding. With respect, I need to see a demonstrated ability to contribute to the Wine project well, and a demonstrated ability to deal with the peculiarities Wine-Staging well, before considering anyone as an additional maintainer. This is not by any means a judgement on you or your ability; rather, as a very new contributor to the project, I simply haven't seen that ability demonstrated one way or the other. I don't know what you mean by "hotfixes", not least because you're publishing them in some non-public place, so I can't really judge from that evidence either.
(And there's no need for anyone to cover any gaps in the schedule; nothing we do is urgent.)
If you want to help wine-staging—and I'm very glad to hear that—I would like to urge you to please, *upstream wine-staging patches*. It's great to hear you want to resurrect patches, but I'd like to make the additional request that you don't just un-disable them, but rewrite them so that they're suitable for upstream.
We need people to lighten the patch load *far* more than we need more people working on rebasing. Not that the latter isn't useful, but in some sense it's a band-aid on the underlying problem that *we have too many patches*. Once we have less patches to rebase, we won't need to spend time rebasing them.
Thanks!
--Zeb
Just to chip in here and add my 2 cents. I completely agree with trying to upstream them but that's kinda hard when they're not being reviewed. I know that's the case for some of my staging patches and I am 100% sure it's for others as well. Obviously, maybe they're not suitable for upstream, but without review it's hard for me to know what to do about them or what to change, considering I also always tried to add proper tests (where feasible). Keep in mind, even if it may be obviously wrong to the maintainer, that doesn't mean it's obvious to the one submitting it if he's not familiar with the module in question for example.
1/6 and 2/6 are pretty much a waste of time for everyone involved, so I'm not going to bother with them. Compilation warnings can be fixed when patches are rewritten for upstreaming.
Alistair doesn't think that's a waste because they pushed various compile warning fixes when 9.0 was only a few days away (so you should probably discuss this with them and come with some sort of agreement) Also if you think these patchsets are hard for you to review I can split them up even further (currently I have them split up into printf format/number cast and interface cast patches) And finally on a unrelated note does the Compiler_Warnings patchset bring any benefit to Wine? The compiler currently does not warn about the implicit interface casts (and I don't think they're causing any issues; removing that patchset could free up some work but that patchset rarely breaks anyway so...)
Wrt 3/6, as I requested before, can you please remove the extraneous noise from the patch set (e.g. moving functions around, changing traces)? It is very difficult to judge whether a patch is doing the right thing when there's all that noise.
I'll try to do something about the wineserver change noise (I think TRACE function changes should stay because they're tiny and they prevent explosions when using the +file channel with the reparse point tests which was important during my debugging sessions)
Wrt 4/6, I don't think it makes sense to remove config options solely because the patches are disabled. Disabling patches is meant to be a temporary measure.
I guess those 2 patchsets should be on my to-do list to rebase and adapt to PE-Unix split then (but you said staging needs less patchsets so I may have to upstream those patchsets which would mean this patchset has to be applied anyway with a different message)
Note though that 6/6 was incorrect as-is; a line was incorrectly dropped. I fixed that to be moved to the appropriate place.
I should be more careful with my rebases then (I already caused some segfaults by doing something wrong in a patch for an unrelated project which caused some appropriate AUR comments)
2. I don't understand what you mean by this, can you please explain?
You mentioned that in an answer to the question of wine-staging not accepting MRs (merge requests/pull requests) when talking in the modern version of IRC (aka Discord) so I want some clarification on that (especially since you wrote a wall of text for question 4)
3. The wine-staging team is documented here: https://wiki.winehq.org/Wine-Staging#What_is_Wine_Staging.3F
The wiki page mentions 2 people (Greer and Crider) I've never really heard of before (are they inactive or are they working on different parts of staging?)
With respect, I need to see a demonstrated ability to contribute to the Wine project well, and a demonstrated ability to deal with the peculiarities Wine-Staging well, before considering anyone as an additional maintainer. This is not by any means a judgement on you or your ability; rather, as a very new contributor to the project, I simply haven't seen that ability demonstrated one way or the other.
So should I make my Wine work public and work actively on the project?
I don't know what you mean by "hotfixes", not least because you're publishing them in some non-public place, so I can't really judge from that evidence either.
By "hotfixes" I meant making staging compatible with newer Wine commits (aka rebasing) but these are quick and dirty (by that I mean modifying the staging patches by hand) I mainly pushed these patches to a channel in a frog Discord server (but no one likely used them anyway so I think I should publish them to a public place like my wine-(dodo)staging repository on GitLab or snippets/gists but I hope that the Robloxians don't accidentally find them)
(And there's no need for anyone to cover any gaps in the schedule; nothing we do is urgent.)
I'm personally fairly impatient (and maybe bored too) so that's why I started poking at wine-staging and making fixes/rebases
We need people to lighten the patch load *far* more than we need more people working on rebasing. Not that the latter isn't useful, but in some sense it's a band-aid on the underlying problem that *we have too many patches*. Once we have less patches to rebase, we won't need to spend time rebasing them.
I think even lightening the patch count by half is probably going to take years with my current level of skill (but I might get better in the future) And one more question that I've kind of forgotten about: Is there a public archive of the bugs that were in bugs.wine-staging.com? Various old Wine resources (and some staging patchset references) are useless because of this (I think Alistair knows about this historical stuff better so they should definitely look at this question) PS: This was one of the longest emails I wrote probably ever (I don't really use email/mailing lists much)
On Sunday, 28 January 2024 11:07:28 CST DodoGTA GT wrote:
And finally on a unrelated note does the Compiler_Warnings patchset bring any benefit to Wine? The compiler currently does not warn about the implicit interface casts (and I don't think they're causing any issues; removing that patchset could free up some work but that patchset rarely breaks anyway so...)
The meat of that patch set is patch 0031 ("include: Check element type in CONTAINING_RECORD and similar macros."). It was submitted once, and got a bit of pushback [1], but it's not clear to me whether it was enough pushback. I haven't tried to gauge whether it'd be acceptable now; I've been focusing on other more important patches first. [1] https://www.winehq.org/pipermail/wine-devel/2016-March/112260.html
2. I don't understand what you mean by this, can you please explain?
You mentioned that in an answer to the question of wine-staging not accepting MRs (merge requests/pull requests) when talking in the modern version of IRC (aka Discord) so I want some clarification on that (especially since you wrote a wall of text for question 4)
I don't know what conversation you're referring to, but we don't take pull requests or patches because they are hard for contributors to get right, and even harder for us to review. You've kind of seen this by now, I hope.
3. The wine-staging team is documented here: https://wiki.winehq.org/Wine-Staging#What_is_Wine_Staging.3F The wiki page mentions 2 people (Greer and Crider) I've never really heard of before (are they inactive or are they working on different parts of staging?)
Thomas Crider joined at about the same time that Alistair and I picked up the project in 2018. He doesn't usually do rebases these days, but does often help with testing. Dean Greer has essentially built the wine-staging CI from scratch, and helped cover Mac testing and fixes, which as you might imagine tends to be an overlooked area.
With respect, I need to see a demonstrated ability to contribute to the Wine project well, and a demonstrated ability to deal with the peculiarities Wine-Staging well, before considering anyone as an additional maintainer. This is not by any means a judgement on you or your ability; rather, as a very new contributor to the project, I simply haven't seen that ability demonstrated one way or the other. So should I make my Wine work public and work actively on the project?
That's preferable to working privately. But also, I wouldn't see "Wine-Staging maintainer" as a goal. Rather, I'd encourage you to consider contributing to Wine itself to be your end goal. Maintaining a project or subsystem is just a duty that goes along with that goal.
I don't know what you mean by "hotfixes", not least because you're publishing them in some non-public place, so I can't really judge from that evidence either. By "hotfixes" I meant making staging compatible with newer Wine commits (aka rebasing) but these are quick and dirty (by that I mean modifying the staging patches by hand)
I mainly pushed these patches to a channel in a frog Discord server (but no one likely used them anyway so I think I should publish them to a public place like my wine-(dodo)staging repository on GitLab or snippets/gists but I hope that the Robloxians don't accidentally find them)
Maybe I'm misunderstanding, but it sounds like you're duplicating the work of rebasing. I don't understand the point of this. Nothing depends on rebases getting done immediately.
And one more question that I've kind of forgotten about: Is there a public archive of the bugs that were in bugs.wine-staging.com? Various old Wine resources (and some staging patchset references) are useless because of this (I think Alistair knows about this historical stuff better so they should definitely look at this question)
There is not unfortunately. If an archive exists, Michael or Sebastian has it, but I've tried to contact them asking for it and been unsuccessful. I'm afraid Alistair does not know any more than I do on this topic (unless I'm mistaken). --Zeb
participants (4)
-
Alistair Leslie-Hughes -
DodoGTA GT -
Elizabeth Figura -
Gabriel Ivăncescu