On Wed, 26 Jan 2005 tony_lambregts@telusplanet.net wrote: [...]
As far as things go until we go to a "Stable release" system then we will always have this problem.
That the problem: a "Stable Wine release" has been six months away since 1998 and even before. But we still don't have one, have no idea when there will be one and thus we should not do stuff that will only makes sense once we will have a stable release and are just confusing and meaningless until then.
When we do go to a Stable release cycle I would expect that part of the criteria for the next stable release would be that all "Gold" applications were still "Gold".
Maybe this is how it will work, maybe not. It would be a big change from the way things work right now and nobody knows when this is going to happen so it's presumptuous to make predictions.
IMHO it's best to focus on the now and do stuff that makes sense now.
In a way it's just a wording issue, I would not be opposed to the notion of 'maintained applications'.
That would be at least one big incentive for someone to become a maintainer. It is critical that the maintainers find regressions in a timely manner in order to do this and without maintainers we can never expect to get to wine 1.0.
Yes, maintainers have a big role to play in helping Wine move forward faster and avoid regressions (by detecting them early). I'd just disagree about the not getting to Wine 1.0 without maintainers but that's not important.
In the mean time applications are supported in the sense that someone is willing to make sure that regressions are at least noted, and that the entry is maintained (write a HOWTO, answer comments, provide a screenshot and in the future ruport bugs).
The level of support that anyone can expect from any maintainer is that they (the maintainer) will try to help the person get the program to run.
This should really go in a "Maintainer's Guide" somewhere.
[...]
CodeWeavers does not make any guarantee that just because one version of a program is supported the next will be (ie Microsoft Word).
I have not claimed that. Nobody can garantee that because Foo 2000 works today, Foo 2003 will work tomorrow on the current Wine, or even on a future Wine in a timely manner (just add some copy protection, a useless driver the app will not start without, or rewrite it from scratch).
So if we had a stable release cycle and CodeWeavers does not change their official support policy. They approach the same meaning.
Yes but Wine does not have stable releases and nobody can say when it will have stable releases. So for the forseeable future they don't have the same meaning.
[...]
That's the thing with numbers (stars) and medals: it's not clear what they mean. It might be clearer to just state: Not tested Does not install Installs Starts up Usable Perfect
Any rating system sucks by definition in my book. You forgot.
Does not install but if copied over from a real windows system runs perfectly.. Does not install but if copied over from a real windows system is usable. I can apply a patch (hack) that Alexandre won't apply and then it will start up. I can apply a patch (hack) that Alexandre won't apply and then it is usable. I can apply a patch (hack) that Alexandre won't apply and then is perfect. I can use sidenet and it works fine.
There are more ....
No. The rating should be taken once you have taken the reasonable steps described in the Application Database. This includes copying some native dlls, installing stuff such as MSI or Internet Explorer beforehand. I think patches and copying from a Windows system should be ruled out because they are too complex (something to define in the Maintainer's Guide).
And all that counts is the end result once you have followed these steps: * Can I at least install it? Matters to Wine developers. It translates to 'Will I be able to debug it?'
* Can I run it? It's a very important step. Until the application at least starts you have no idea how much stuff is broken.
* Is it usable? Users want to know if they will be able to do anything with it. If the application is marked as Usable then yes. Maybe some functions won't work like printing, maybe burning CDs or other stuff like that and these should be listed but not everyone needs them. What counts is the core functionality.
* Perfect The application is fully usable.
That's all that matters to users.
There is no way around the fact that if a program is not "Gold" or "Perfect" you need a at least a HOWTO.
Even Gold or Perfect may need a HOWTO. If you can make the application run 'perfectly' by using native comctl32.dll, then it should still deserve its 'perfect' status.
As for the maintainer vs. user rating, both should use the same system since they are both doing the same thing. It's just that the maintainer rating should be given a more prominent place.
If it was up to me I would eliminate the the user rating. (But thats me.)
I would not be strongly opposed to this.