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