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:
- 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.
- 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?
- 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
- 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.