Wine developer frustration (was Re: ntdll: Improve stub of NtQueryEaFile.)

Caron Wills caron at
Wed Jun 17 12:05:51 CDT 2015

This strays from the thread topic a bit but I wanted to toss in my thoughts.

I believe that Rosanne makes a valid point: It's hard for users to know where to file a bug.

I would like to add that users are showing up in all of the derivatives of Wine as reports that "it works here!" without fully understanding what that means or how to explain it (in the worst scenarios, in the best they do it perfectly!). Wine-Staging adds another layer but to the average user it only means their beloved application works somewhere and that's ultimately what led them to Wine & company in the first place. With this, it is difficult for users to know when and where to file a bug or show where it's been fixed and to grasp why it is marked fixed one way but not another. Some obscurity has always been there because of the various projects but Wine-Staging understandably adds to that.

The user side is a different part of the conversation but whatever path is taken, it will affect people coming to any of the Wine subsets. I don't know if I disagree with bugs being closed if they mention Wine-Staging as bugs are closed if they mention Winetricks, PlayOnLinux/Mac, CrossOver, WineSkin, WineBottler, and any of the others. It would be gentler to ask, "does this happen in vanilla Wine" and if a person can't test it or doesn't have the skills, redirect them to the appropriate place with closure of the WineHQ bug. I've actually seen similar action to this on every "closed invalid" bug I've reviewed that mentions a third party. Many kudos to the people triaging WineHQ bugs.

How much work flow would it add to allow a person to retest the bug in Wine without closing it on the initial pass? And to comment back if they can't? How often would they?

I think the Wine-Staging team has done what was requested and has made it possible to tell if output/logging comes from them. Running a Windows application out of Wine-Staging right now, the first two lines in the output are:

fixme:winediag:start_process Wine Staging 1.7.45 is a testing version containing experimental patches.
fixme:winediag:start_process Please report bugs at (instead of

Thank you. And my favorite comment to this is:

”Ack, you're right. Mea culpa. Apparently the giant "this is staging" warnings were being squelched on my end. Will repost there."

I'm not sure if there's more that can be done to distinguish when an application is running in Wine-Staging versus the others. How much more do we need in log files?

The hard messaging I see about Wine-Staging is on this page:

"Fedora for example ditched their regular Wine version and replaced it with Wine Staging."

In the threads about Wine-Staging on wine-devel, it's apparent that the Fedora team was discouraged from doing this but on the Wine-Staging landing page it feels more like a selling point. I understand the importance of stating the above in a positive way but I wonder if this statement isn't a little over the top.

If I could wave my magic wand, I would wish for some sort of peace with Wine-Staging because they have done some very positive things:

* There are (or seem to be) more active responses to queries on wine-devel, isn't that what everyone wanted?
* There are patches that have made it into Wine with assistance
* There are people testing out patches that are not yet in Wine but need review (and it was my understanding that it was difficult to get people to test single patches)
* There is a growing community using Wine (regardless of what flavor)

Wine-Staging is no more evil than the rest of us and at least from my point of view, we're all here to make a positive difference in Wine.

Many thanks for your time,

-----Original Message-----
From: wine-devel [mailto:wine-devel-bounces at] On Behalf Of Rosanne DiMesio
Sent: Wednesday, June 17, 2015 10:13 AM
To: wine-devel at
Subject: Re: Wine developer frustration (was Re: ntdll: Improve stub of NtQueryEaFile.)

On Wed, 17 Jun 2015 21:25:11 +0800
Tom Wickline <twickline at> wrote:

> Problems / Solutions :
> winehq doesn't want wine-staging bugs in their database , simple fix, 
> wine-staging should look into hosting their own bug tracking database 
> and tell users to file bugs here and not their.

Wine-staging already has its own bug-tracking database. The problem is that the inexperienced users they are so aggressively marketing to can't reasonably be expected to figure out on their own whether a bug is in mainline Wine or one of the 600+ experimental patches, and simply telling those users to file everything over there will result in bugs that belong here not being reported here. 

Rosanne DiMesio <dimesio at>

More information about the wine-devel mailing list