Am 22.02.26 um 8:02 PM schrieb Elizabeth Figura via Wine-devel:
On Saturday, 21 February 2026 01:45:41 CST David Kahurani via Wine-devel wrote:
On Sat, Feb 21, 2026 at 6:07 AM Alistair Leslie-Hughes via Wine-devel <wine-devel@list.winehq.org> wrote:
Binary packages for various distributions will be available from: https://www.winehq.org/download
Summary since last release * Rebased to current wine 11.3 (241 patches are applied to wine vanilla)
Upstreamed (Either directly from staging or fixed with a similar patch). * mshtml: Add IXMLSerializer implementation.
Removed (No longer required). * 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 It really doesn't look like you're doing much ;-( I'm afraid that fixing and upstreaming a wine-staging patch is a lot of work. Neither Alistair, Paul, nor I has a lot of free time in which to do that work, and I can say that I at least have a lot less free time than I used to for various reasons. To make matters worse, compared to seven years ago, the patches that are left in wine-staging are the harder ones, taking a lot more effort to understand and rewrite. We took care of most of the easy ones first.
I've been working on rewriting inseng-Implementation, which is a difficult task; it's a 3500 line diff that needs to be properly split (I'm anticipating dozens of patches by the time I'm done), needs tests added (it has none, and pretty much everything in inseng can in fact be tested); the INF parsing stuff should almost certainly be rewritten on top of setupapi (I don't know why Michael wrote a custom parser), and I need to see if the urlmon stuff can be redone on top of an API that's less horrible than urlmon. I'm anticipating the whole thing will take me a couple more months at the current pace.
Meanwhile, I just got done implementing reparse points upstream, a month-long effort if you don't count the regressions (or the Unix symlink support, which isn't done either), and ntsync, a project that started in late 2020. And in both cases I was lucky enough to be able to spend actual work hours on them. Most wine-staging patches aren't anything that CW's clients care about. inseng certainly isn't.
The goal of Wine-Staging since we took over maintainership was supposed to be a restoration of its original stated goal—to provide a place where patches not ready could be tested and incrementally improved, then submitted. But fundamentally Alistair and I were first and foremost rescuing the project, and we never had the time to execute this goal like it perhaps deserved. Not to mention that the "incremental" part ends up kind of being a waste of time—it's far less time-consuming to just look at a patch, fix everything wrong with it at once, then submit it upstream directly.
At this point I'm almost the only one working on wine-staging patches, so frankly, hearing anyone complain about the lack of progress is a little frustrating. If you'd like to see more progress I would beg you to upstream wine-staging patches yourself. (Critically, that doesn't just mean taking a patch and throwing it upstream. Patches are in wine-staging for a reason, and they need to be improved first.)
--Zeb
I'm sure some of the patches would be difficult to handle. I'm just wondering why "fonts-Missing_Fonts" is not upstreamed yet, it seems simple, and a lot of applications would benefit from this. A brief review of the license terms does not show any red flags to me. What needs to be done to get these in ? More general speaking, there are many patches that seem simple, and have a reference to a bug report that is (supposedly) fixed by that patch, but it is not clear what the problem with those patches are (I just checked msi-cabinet, mountmgr-DosDevices, wine.inf-Dummy_CA_Certificate ). A list of review status, of each patch set, could be beneficial to share the workload. e.g. - no reviewed - no ready for upstream/needs more work - missing tests - should be considered by upstream I understand also that reviewing patches of others takes some effort. And accepting patches that you (and other maintainers) are not comfortable with (i.e. increasing technical debt) is a really issue, too. In cases when you do not have a hard reason to reject a patch set, you could accept it (perhaps limiting this to one per release cycle), and check only afterwards whether some problems pop up - the automated tests as well use user feedback seems powerful enough to handle this. This could really help to reduce wine-staging patch sets. --Alois