Wine staging tree

[Henri Verbeet]

On 6 October 2014 10:51, Stefan Dösinger <stefandoesinger at gmail.com> wrote:
> Am 2014-10-06 08:13, schrieb Henri Verbeet:
>> There's no reason the D3D command stream work couldn't have been
>> done against upstream Wine, and in fact that's exactly what I did
>> before handing it over to Stefan. (For reference, one of the first
>> commits for that is 1ef4f075c160a826a57e8cf5613a3211005c8eb9.)
> I don't think so, mostly because it's next to impossible to upstream
> something that has a reasonable probability to need reworking later
> on. E.g. I went through a number of iterations of ways to handle
In my experience that's not true at all, unless you actually mean "is
obviously going in the wrong direction" with "has a reasonable
probability to need reworking later on".

> resource updates until I found one that actually works with real-world
> OpenGL implementations, and I know even the current way is flawed,
> even though it works in practice. Yet I believe writing the current
> code was essential to find out what the actual driver limitations are
> and which requirements/bugs games have.
>
There's of course no reason you can't test your own code without a
staging tree. And quite frankly, almost all the work I did on the
command stream without a staging tree is upstream, and very little of
yours is.

There are probably legitimate arguments for having a staging tree, but
the wined3d-csmt tree is more of an argument against than for.
Properly maintaining a staging tree is real work, and not necessarily
a lot of fun. Historically these kinds of trees haven't ended up being
an overwhelming success, but who knows, perhaps this time will be
different. As long as it doesn't take away too much from the already
somewhat limited testing done against the main tree, I just wish
everyone the best of luck. (I.e., I'm fairly skeptical this will work
out, but as long as it doesn't cause the project too much trouble I
see no reason to tell other people what to do with their free time.)