ntdll: Improve stub of NtQueryEaFile.
mstefani at redhat.com
Thu Jun 11 03:35:47 CDT 2015
On 06/11/2015 10:14 AM, Alexandre Julliard wrote:
> Sebastian Lackner <sebastian at fds-team.de> writes:
>> I never encouraged anyone to give up on WineHQ, and I also haven't given up
>> WineHQ myself. If you mean the fact that Fedora switched to Wine Staging, I
>> even advised them against doing this, when they contacted us about a year ago.
>> In fact I would love to see a huge amount of our patches go upstream, and to
>> work more directly together with upstream developers, with the common goal to
>> make Wine better for the whole community.
> I don't mean Fedora, though that's probably not a good thing either. My
> problem is the whole parallel process thing. In order for me and other
> devs to understand what's going on with your patches, we would now have
> to follow two bug trackers, two IRC channels, two mailing lists, github,
> etc. And of course it's even more confusing for users, who won't
> understand the distinction between the two.
> Why not use the tools we already have (and improve them if they are
> insufficient)? If you truly want to work with upstream developers, why
> are you not discussing your patches on wine-devel or #winehackers?
That is partly history as Wine Staging started from the pipelight
project. And partly because from the beginning Wine Staging was seen as
an evil fork by some core Wine developers which has no place on the
"true Wine" infrastructure and thus was met with active hostility.
But I agree, e.g. it is really stupid that Wine Staging has to spin up
their own bugzilla. But what should they do else when the user bugs are
closed on bugs.winehq.org with RESOLVED INVALID "evil 3rd party fork"
even though the bug is in upstream Wine too. And that is not helped by
you being "not convinced" and people having to prove them self before
you giving out access on the official winehq infrastructure.
More information about the wine-devel