Alexandre Julliard wrote:
We do have a bit of merge work pending for non-3D components, which we hope to get to soon. The delays there have nothing to do with licensing issues though - they're more about development process and CVS policy.
It may be a good idea for you to give some more details about that; it would probably help clear up some misunderstandings.
Sure: We have a separate CVS tree that we use for our releases, which we're now doing roughly monthly. We try to ensure that we have a period of relative stability in tree before releasing. Merging from WineHQ into our tree is very destabilizing for us, especially given some of the rearchitecture work that has taken place recently. For example, moving window-list-walking into the server gave us a 20% or higher performance loss in many games due to the increase in server-call overhead; one of the fixes in our pending queue deals with this problem.
Because of this, we tend to try to minimize the inward merges we do (our last was over 2 months ago). This, in turn, makes outward merges more difficult for us.
In addition to the above, another problem we face with merging is that the D3D code has tendrils in the core DirectDraw code which makes seperating the two for licensing purposes challenging.
On the flip side of things, you are more strict about the code that goes into WineHQ CVS than we are on our side. We have a number of changes on our side that provide useful functionality, but are not clean enough or proven enough to go into WineHQ. IE: the patch that we recently submitted for [Read/Write]ProcessMemory. It works for the problem we were experiencing (a copy-protection related thing: the various protection systems tend to use WriteProcessMemory all over the place), but you raised some concerns about other cases and wanted to see some of the trace data which we have not had the time to put together.
Some of the other things that we have in our tree that fall into a similar catagory are: - GDB Remote debugging - Gerard Patels' deferred tracing patch - Auto-detection & adding of CD-ROM devices - The heap management fix discussed in October
Note that I'm not saying you're wrong to not include these in WineHQ CVS. There are certainly many benefits to keeping the tree under strict control, as you have, but the difference in policy has a tangible effect on the ease of our merge process.
I think that the strictness may also have other effects on the speed with which the project progresses. Certainly reviewing wine-patches and doing the CVS commits and testing must take up a large portion of your own time on the project.
I understand very well that you don't have time to spend on merging, but you don't have to: all you have to do is slap the Wine license on your code, and I'm sure someone else will be happy to do the merging for you. The fact that you don't do this gives the impression that you don't want to make the code available, even if that's not your real intention.
Well, as I mentioned above, a certain amount of work on our part is required to properly separate 2D code from 3D code. Once we've had a chance to do that, I would be happy to accept help with our next outward merge. I spent a bit of time this evening preparing a diff of our code against our previous inward merge, and doing a rough first cut of code that can go to WineHQ (about 10k line of diff). If there's a real interest in helping us merge this in, I'd be happy to fix it up a bit more and post it to the mailing list under the Wine license.
-Gav