On Friday, 26 January 2024 16:35:16 CST DodoGTA GT wrote: 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. I don't understand what you mean by this, can you please explain? The wine-staging team is documented here: https://wiki.winehq.org/Wine-Staging#What_is_Wine_Staging.3F 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

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...) 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) 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) 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) 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) 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?) So should I make my Wine work public and work actively on the project? 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) I'm personally fairly impatient (and maybe bored too) so that's why I started poking at wine-staging and making fixes/rebases 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)