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)
- 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)
- 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)