Wine staging 11.3 release
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 Best Regards Alistair.
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 ;-(
Best Regards Alistair.
On 2026-02-21 09:45, 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: ...
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
It really doesn't look like you're doing much ;-(
David, as a mailing list old timer I'd say feel free to contribute! :) S.
On Sat, Feb 21, 2026 at 12:19 PM Saulius Krasuckas <saulius2@ar-fi.lt> wrote:
On 2026-02-21 09:45, 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: ...
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
It really doesn't look like you're doing much ;-(
I just did
David,
as a mailing list old timer I'd say feel free to contribute! :)
S.
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
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
On Mon, Feb 23, 2026 at 12:24 PM Alois Schlögl <alois.schloegl@gmail.com> wrote:
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 have probably over 20+ stale Linux patches, because no-one will take them.
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
You gonna teach me how to do this? On Mon, Feb 23, 2026 at 12:34 PM David Kahurani <k.kahurani@gmail.com> wrote:
On Mon, Feb 23, 2026 at 12:24 PM Alois Schlögl <alois.schloegl@gmail.com> wrote:
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 have probably over 20+ stale Linux patches, because no-one will take them.
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
On Monday, 23 February 2026 03:24:03 CST Alois Schlögl via Wine-devel wrote:
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 ?
The fact that the license is different at all is concerning. I haven't tried to submit it yet, but it gives me the vibes of being a thorny case, and I try to at least space those out so as to not overwhelm Alexandre with hard problems. Currently I think there's still more work to do on reparse points, and then after that I was planning to work on a category of problems related to device paths, which also touches very low level code and has the potential to be thorny.
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 think in most cases it really is just a matter of someone needing to take the time and effort to look into it. Some patches aren't even "hard" per se, honestly; they're just areas that I'm still not familiar with and so I'd need to do a bunch of research to understand what the patch is doing. Many patches really just need a ruling from an upstream maintainer, which has often been very hard to get, although to give credit I've had an easier time recently. Some patches are also written by an active contributor, and so I tend to not look at those on the theory that that contributor will submit them upstream themselves at some point. Granted, some have been here for years... That said, in some cases there are known problems that could be publicly documented. I'll start working on describing some of the known problems with patches and putting them in the "definition" files, which is where some that information already goes. As for the ones you specifically called out: * msi-cabinet I think just needs a test. * mountmgr-DosDevices could use a test, and investigation of whether this is the correct path to write. It's also something I was going to look at while working on device paths, as well as ntdll-NtDevicePath and ntdll-NtQueryVirtualMemory. * wine.inf-Dummy_CA_Certificate is probably just the wrong way to solve this problem, but I don't know. Likely we should add a real certificate.
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.
I think the problem that's not really evident to people—and the reason that wine-staging was never as helpful as people thought—is that "testing" is very rarely what patches lack. I think at this point, the average wine-staging patch set is less likely to cause regressions than many patches that are committed upstream. Patches that have a hard time going upstream are almost always stuck because they're architecturally ugly, and committing them would introduce a maintenance problem, or because they're simply architecturally *wrong* and would need to be redone from scratch at some point. That's not something that being in wine-staging can really fix, and I doubt it ever could. The people who are reviewing patches in wine-staging at this point (i.e. mostly just me) are also reviewing patches upstream. --Zeb
participants (5)
-
Alistair Leslie-Hughes -
Alois Schlögl -
David Kahurani -
Elizabeth Figura -
Saulius Krasuckas