Summer of Code and Projects around Wine

[Zebediah Figura]

Hello Joshua,

On 2/21/20 9:05 PM, Joshua Ashton wrote:
> *//*My dude,
> 
> You don't need to be so subtle in your wording given you've told me 
> explicitly before when I reported an esync bug that was *completely 
> unrelated* to D9VK:
>  > "anyway, your project does not benefit Wine at all, so I have no 
> incentive to help it. if you ever feel like benefiting Wine, come back 
> and then we'll talk"
> If you genuinely feel that DXVK has no benefit to and no part in the 
> "Wine ecosystem" then /shrug
> 
> Our projects serve entirely different purposes and have entirely 
> different development philosophies.
> The whole reason I left CW and perused D9VK independently was simply 
> because I wanted to *avoid* all the potential drama of me working on 
> D9VK full-time because I knew it was inevitable and I didn't want to 
> sacrifice my career safety over stupid petty drama that always seems to 
> come up.
> 
> WineD3D is good at what it does, and it serves its purpose well, but:
> When I was brought on to work on that, I was way more interested in what 
> could potentially be done without caring about the limits of maintaining 
> such immense backwards compatibility (ie. OpenGL and especially super 
> ancient GL.)
> I think that the WineD3D backend is completely GL-centric and detaching 
> that in a way where both renderers work using common code and you still 
> get any advantage from using Vulkan seemed waaayyy more work than adding 
> a D3D9 frontend to DXVK from scratch.
> 
> I wanted to do things my way as well -- and my way would not be accepted 
> in Wine due to the C89 mandate; to me, implementing COM + D3D in C++ is 
> much nicer: having genuine shared bases for unknown, device children, 
> RAII for ref counting (COM, private COM, and internally.)
> 
> I'm really not a fan of WineD3D's command stream implementation, it's 
> really annoying to follow what a function is actually doing -- but I 
> understand that doing that in C89, it's probably the cleanest it is 
> going to be.
> Defining command stream functions via lambdas (ie. we can combine stuff 
> into a unique (or automatically shared if it's the same!) CS func in a 
> function) is super nice and easy to follow and something I definitely 
> wouldn't want to give up.
> 
> I am not saying I think C++ is a good language overall, but for 
> implementing a C++ API, I would definitely say it is a good choice. :P
> 
> I also don't have to maintain compatibility with however many versions 
> of Office, GCC, etc -- nor do I have commercial customers that depend on 
> that. I'd prefer to make an effort to improve performance and have some 
> regressions from stupid mistakes I make than to have to worry about "if 
> it ain't broke don't fix it." -- I don't have that concern, but you 
> guys' commitment to compatibility like that is certainly respectable and 
> commendable. :)
> 
> Hopefully this helps you to understand my viewpoint...
> I don't have any disdain, grudge or hatred against you or what you work 
> on; (at the very least) the d3d9 frontend of DXVK wouldn't exist without 
> WineD3D as an occasional reference.
> I would like to improve our relationships and for us all to get along 
> without this weird tension and passive aggressiveness -- admittedly from 
> both sides at times.
> We're all human! (or frogs in my case. :P) 🐸

It's not my intent to personally attack you, DXVK, D9VK, or anyone else. 
For that matter, Philip Rebohle has several times contributed patches to 
Wine. I'm simply trying to make the point that it doesn't make much 
sense to sponsor projects that aren't part of Wine, if the work that 
comes out of those projects isn't directly flowing back into Wine.

Many projects benefit Wine indirectly—DXVK is of course one—but it would 
not make sense for Wine to sponsor a GSoC project to work on, say, 
GStreamer, or the Linux kernel.

On the other hand, it might make sense to sponsor a GSoC project to work 
on Wine-Staging—it's essentially a forked codebase, but its patches flow 
upstream (given enough time on the part of the Staging maintainers...)

> 
> If you want to speak more you can always email me or whatever. :)
> - Josh 🐸
> 
> ---- On Fri, 21 Feb 2020 16:06:15 +0000 *Zebediah Figura 
> <z.figura12 at gmail.com <mailto:z.figura12 at gmail.com>>* wrote ----
> 
>     On 2/21/20 1:20 AM, Stefan Dösinger wrote:
>      > Hi,
>      >
>      > Since we had troubles getting GSoC students and project ideas in
>     the past year I'd like to bring up a controversial suggestion: Talk
>     to the projects that popped up around Wine like PlayOnLinux, Lutris,
>     DXVK if they have GSoC-compatible ideas and host them as a Wine GSoC
>     project.
>      >
>      > Ideally those projects would be something that reduces friction
>     between upstream Wine and other projects. E.g. on FOSDEM I talked
>     with Josh Ashton and he mentioned d3d behaviors that some games
>     depend on for which we don't have tests and that sometimes work in
>     wined3d by accident or don't work. Syncing those lessons by writing
>     and upstreaming proper Wine tests would be a valuable thing for
>     everyone.
>      >
>      > I don't know enough about PlayOnLinux or Lutris to suggest
>     anything outright, but I still think it's worth asking them.
>      >
>      > Cheers,
>      > Stefan
>      >
> 
>     I think it's worth asking at least if helping the project will benefit
>     Wine in some way. I know that some of those projects have helped the
>     Wine ecosystem and even sent patches upstream, whereas some have
>     decided
>     not to do so and instead to be an independent fork.
> 
> 
>