Is Wine a platform for Codeweaver to make money?! Please help
Philip A. Marshall
marshall at ece.ualberta.ca
Tue Apr 10 18:17:23 CDT 2007
On Tue, 2007-04-10 at 13:13 -0500, Jeremy White wrote:
> Hi Philip,
> Philip A. Marshall wrote:
> > While we're on the subject, I've got a question about the situation. I
> > know I can go to Codeweavers and download the source for crossover wine.
> > But, if someone is trying to review codeweavers patches to "fix them up"
> > for wine, that isn't very convenient (I can't imagine a diff of the
> > entire source, or even one file, being useful). I know that a lot of
> > codeweavers patches get submitted to wine, but do ALL of them? Is there
> > a way to access the codeweavers wine development tree? I ask because
> > I've seen people post here "There's a hack in crossover that makes that
> > work, if you want you can clean it up for wine." I'm just curious as to
> > how easy it would actually be to do that.
> Our policy is that all of our work on Wine is submitted to wine-patches *first*.
> (There are rare exceptions, but they happen more because of old branches
> that are out of sync, or rush jobs, but the basic principle follows
> for 99% of our work).
I assumed this is what happened since it makes it easier to keep trees
in sync (hence a mutually beneficial solution in the long term), but
thanks for the confirmation.
> The only time we apply a hack is when there is a practical solution
> that is offensive to the @#$@#$ Wine maintainer.
Hah, I'm aware of the differing standards between the two projects,
hence the curiosity at the process by which differences were managed.
Incidentally, I'm not going to weigh in on which set of standards I
think are "right", because as far as I'm concerned they're both "right"
for the project they're applied to. It's a bit like a "stable" and an
"experimental" branch. It will be interesting to see what happens after
1.0: whether "hacks" are more likely to be accepted into the winehq
development branch but not merged into trunk releases, or whether
they're still rejected for the same reasons they are now.
> Frankly, your best bet for leveraging our work is to use Wine from
> WineHQ first. If you run into a problem, it's useful then to compare
> it with CrossOver, to see if the behavior is different (90% of the time,
> we have the identical bug). If you do see that CrossOver is better,
> then the next steps that would be useful would be to look into our
> DLL overrides and try to configure winehq to follow; I'd bet another 50%
> of the time that will explain the difference. Next, download our
> Wine source tarball and see if our Wine works when public Wine doesn't.
> Then, and only then, would it be worth digging into our source to
> see if we have a special hack. And your best bet would be just to
> grep for the application you're trying to run; we usually put
> a comment in our code like "Special hack for Shockwave."
Thank you, this is exactly what I needed to know. That's certainly a
sane way to go about things.
More information about the wine-devel