[Wine] Playonlinux and Office 2007

[James Mckenzie]

oiaohm <wineforum-user at winehq.org> wrote:
>
>>GNU_Raziel wrote:
>>Wine does not try to forget items Like steam.  But its insanely hard to keep working due to how much it
>>changes and limited supplies of testers for it.
>
>Some of those issues we have with games and the like are from lacking people with the software to keep testing and
>reporting.
>
One of the major problems I can find is that the forum passwords and the Applications Database passwords are not synchronized.  Thus when a user finds a problem or wants to report that 'all is well' they have to create a second account.  Some folks have even stated this and they would like to report but tracking multiple userids and passwords is a problem for them.
>
>> So all this to notice you that, most POL/POM users will probably not report anything since we do all we can to make
>>their apps work "out of the box" from their point of view. I, myself, do not try to add games to POL/POM that are not
>>reported in AppDB as working because I cannot buy a game that will not work just for test/report with wine, I have not
>>enough money for that Razz
>
>This is the issue wine people have as well.   Also we have issues were games don't work with particular video card drivers
>and the like.
>
The problem is not a lack of funds, it is a total lack of time for most people.  Once the program does what they want it to, they stop trying to improve things.  Thus we get regressions that are not discovered until 'someone new' comes in and states "The Applications Database has ProgramX rated Platinum and I cannot even get it to run".  Then we discover that a patch three versions back broke the program.  Very hard to fix now.  If we had someone with a lot of time that could just pick up a program and test it DAILY, then we would be further ahead in removing/fixing regressions.  Susan Cragin was doing this for Dragon Naturally Speaking until either something happened in her life or she just gave up.
>
>We try to get app maintainers in the appdb to keep on reporting status of there apps.
>
But they, too have this thing called 'real life' and sometimes do not run their program for three or four versions.  Again, it would be nice if they did so for each release version and maybe more often.
>
>Big problems wine has is not enough testing to find regressions.   If  wine know about regressions inside 1 or 2 versions
>they can normally be fixed simply.   But if wine find out like 10 to 12 down the track.   Problem of fixing can be 
>insanely harder because a lot of code can be depending on the alteration that caused the problem.
>
There are folks that did not run their program except when Wine 1.0.1 was released.  Now they are trying to update to Wine 1.2 and find that the program no longer installs.  There were approximately 3500 patch commits between the two releases over a two year span.  Regression testing this is very tedious, time-consuming and may point to multiple patches contributing to the inability to run the program.  Not a good situation.  This leads to the "I don't want to run a development build, it might break my system" problem.  Creating a third category of "Testing builds" or beta runs, may aleviate this, but that increases the complexity of Wine code and tracking these builds.
>
>You will see the games with more regular reporting on the appdb will have less over all issues.
>
True.
>
>The issue here I know what we need so we can reduce failures.   Its testing by the people with the games.   Problem have
>people with the games may not be skilled enough.   Now we don't need everyone with the game to report if they did they
>would overload the appdb.   We just need 3 to 4 per game in most cases.
>
And those people should be running different Linux distributions and different hardware.  Some patches will only affect a limited number of people.  Thus, a proposed 'fix' that breaks some people but not others can be detected and corrected quickly.
>
>Problem here is freezing on old versions of wine you end up slowly but surely  becoming current day hardware and
>distribution incompatible.   So we need to maintain forward movement.
>
How often does Ubuntu/Fedora/Debian do a full release.  Maybe once every six months.  However, a patch/fix from them may break Wine or vice versa.  These problems need to be identified and corrected.
>
>GNU_Raziel I know its simple to say lets stay still.  But we are sitting in a area if we don't stay moving we will die.
>
Standing still will not result in death, but you will find yourself falling further and further behind.  If Wine releases a development/test build, POL should at least try to see if it breaks or improves program use.  If it breaks programs, this needs to be reported, quickly.  If it improves program usage, that needs to go into the Applications Database.  This could be done by the POL package maintainer as part of their duties, just like it is supposed to be a part of the duties of a Wine Application Maintainer.
>
>Basically wine need your adventure seeking users who are prepared to experiment and report.   I know they are a small
>percentage of your user base just like they are a small percentage of the wine userbase.   We need them with a path that
>they can start out simple.
>
I agree.  One, two maybe three users per package that can report successes or failures back to the POL/POM project is all we need.  This maybe out of thousands of POL/POM users.  This will help POL and Wine detect breakages and improvements quickly and prevent what is becoming 'regression hell' when we find out that Office 2007 will not install and could not be installed for several Wine releases.  We need to discover that 'rouge' patches do or do not work so that the patch creator will be encouraged to fix the patch so that it meets Wine's high standards and to move some patches from 'hack' status to 'committed' status.

I am of the opinion that POL is an excellent place for this to happen, but it appears that the people who run the POL/POM project are being reluctant in doing so.

James McKenzie

>
>
>
>