http://wiki.winehq.org/WineReleaseCriteria This is kinda the rough roadmap. Wine works the the goal model. List of objectives are put down once done release cycle starts. Release cycle is pure bug fixing and regression removal. After release wine return to its normal develop new features fix applications faults one by one. Objectives are normally based on the parts causing the most problems to the most applications. Pattern works quite well. When release cycle enters particular applications can be picked to be fixed up to fully working as well. > It would be cool to see some kind of subsystem diagram with little percentages in it so we know whats up in a single page. Wish we could. But we cannot. Windows updates change the subsystems. Closest we have is this. http://test.winehq.org/data/ With the test suite what is wine has tests for we know and if it is bust or not. Particularly note the windows it not constant itself. That completely ruins the complete idea of subsystem diagram with percentage complete. Percentage complete compared to what version of windows. Test cases are getting better. Even then MS adds new api's so making percentages out. The test system has been one of wine biggest regression stoppers. Lot of projects to learn from wine methods. Fast development requires functional testsuite being run on patches all the time. MS Office is a more complex program than most people presume. Makes most game engines look simple. Something people miss is that MS Office itself uses Direct X. So lot of fixes for Direct X games are also fixing versions of MS Office faults at the same time. Yes interrelationship is a bugger. It is rare for applications to truly have 100 percent unique faults in wine. Many effect multiable applications. Problem is they don't always appear the same. Ie two bugs that can look completely different can be the same bug. Due to this is very hard to say only fix MS Office bugs. Since its very hard to detect what are the MS Office bugs in the bugzilla. Same applies for other applications. Games have the advantage of being simpler in a lot of cases to see the Direct X bug. Where MS Office has it under multi layers of stuff. So yes lot of issues in MS Office has disappeared as Direct X has been fixed up. Yes a lot of people would love to focus on MS Office or equal and get that out the way first. The API layer is not that nice to us. It also worse with a lot of games and other programs. Wine developers can sometimes contact the makers and say hey what is here ment to be doing and get a response of it should be doing X. So making the bug more solvable in s short time frame. A relationship with MS does not exist like that. Some are simple to detect what application they link to. Like the itunes usb support for devices. But even that there are other programs that if they can get access to USB could do magic. Now making a list of applications that will be helped by the itunes patches will be hard. MS Office also has the evil of reaching out to IE heavily. IE license means we cannot legally ship it everywhere. So its functionality is having to be rebuild piece by piece. Basically asking wine to fix MS Office is asking wine to fix one of the most complex programs on Windows by a large margin. Of course we will welcome anyone attempting to take on that beast. By the time MS Office works most likely everything else will other than odd ball copy protections. Remember some of the newer MS Offices have driver based DRM systems built in as well. Yes of all the hell in 1 program. Yes we know lot of windows users have it. Simplest solution please migrate to libreoffice so solving that problem. Wait that is not suitable to a lot of people. Yes serous-ally Migrating to another office suite is many times simpler than getting MS Office in wine to work 100 percent even if we are talking about a full country. MS Office is deceptive for how complex it really is.
