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