http://bugs.winehq.org/show_bug.cgi?id=2398
------- Additional Comments From phil@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.