[Bug 2398] Application interface (LightWave 3D) completely unusable

[Wine Bugs]

http://bugs.winehq.org/show_bug.cgi?id=2398





------- Additional Comments From phil at ldex.terica.net  2005-02-10 09:38 -------
Where to start? :)

First off, if any major change is implemented that will probably or definitely
cause widespread regressions, it is arguable that the policy should be to have a
legacy switch until the new system has been tested and fixed. Shipping a broken
implementation with no fallback is bad practice and actively prevents me from
testing new Wine releases, bug fixes or not.

Note that this also addresses the 'upgrade or we don't support you' point made
by James Hawkins : I cannot test because the app is completely unusable as a
result of this all-or-nothing approach. I reported the issue as soon as I was
aware of it and spent a good deal of time finding out what patch broke the
system (I suspect many would not have bothered). Those with the intimate
knowledge of Wine haven't been able to fix it yet, for one reason or another
(motivation strikes me as a troublesome reason, given the size and impact of
this problem, but I don't question it). That leaves me out in the cold. I simply
don't have time to learn how to hack on Wine - my days are very busy with RL
stuff (especially at the moment) - and even if I could, those who wrote the code
are likely in a better position to fix it or provide a fallback method.

Without wanting to appear obnoxious, the delay on getting a fix to this issue
also impacts my willingness to test new releases. This issue remains in place 8
months after it was reported and very close to a 1.0 release. What purpose
testing and reporting bugs if the result is no change? I appreciate that
volunteers are working on the code and have in fact a current license for
CodeWeavers CXO product. CodeWeavers wash their hands of the problem because
this isn't a supported app; in fact with the previous code it could very well
have been and I could have easily demonstrated this. Right now, though, this
single issue is preventing that. Volunteers are not obliged to fix this either,
I know. I'm not saying that they should, but am making the case for a policy
change to implement compatibility switch in order to prevent this kind of major
breakage being a blocker in future. I activate the compatibility switch and can
immediately upgrade Wine without losing my ability to use apps that worked
before; I can still test the new code by removing the compatiblity switch. Easy,
effective and painless for almost everyone.

Lionel, I'm afraid your reply makes the case for a compatibility policy for
major changes. I'm relying on your level of motivation for a fix. It's therefore
completely open-ended in terms of when a fix might be implemented, if at all.
That's entirely your right as a contributor, but doesn't help any of those folks
affected by this change. Your code ends up being untested because either the
users go back to Windows (possibly swearing off Wine for life - worse still if
they were developers looking at Wine for making a linux release of their app) or
they run an old version of Wine.

Wine is a major part of the linux desktop scenario and it needs to be reliable
(even as alpha software) and reasonably well planned. Until this issue, for me
it was. If you cannot find the motivation to fix it, some wider publicity of the
problem would perhaps be beneficial - maybe someone else can fix it.

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.