ntdll: Improve stub of NtQueryEaFile.

[Michael Stefaniuc]

On 06/11/2015 11:33 AM, Marcus Meissner wrote:
> On Thu, Jun 11, 2015 at 10:35:47AM +0200, Michael Stefaniuc wrote:
>> Alexandre,
>>
>> 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.
> 
> I just looked at wine staging git.
> 
> It is basically a Wine fork already.
> 
> ls patches/|wc -l
> 228
> ls patches/*/00*|wc -l
> 655
> 
> This includes some larger rewrites of subsystems, e.g. wininet-Cleanup
Marcus, a lot of those patches were already in the Wine ballpark. The
majority of those patches were picked up from wine-patches or from bugzilla.

> Some form of coordinated effort should probably be done to integrate
> things back to wine.
> 
> Also, I sent two more or less trivial fixes towards wine-patches, I would
> really encourage to send more obvious things directly to Wine itself.
Correct. Somebody needs to just do it and see Wine Staging just as a
patch summary like https://source.winehq.org/regressions is the
regression summary. But instead of seeing it as an useful tool some core
Wine developers prefer to look at it as an evil fork and actively fight it.


bye
	michael