Forwarding in case someone cares about this.
Ivan.
Ivan Leo Puoti wrote:
Forwarding in case someone cares about this.
Ivan.
Subject: Wine-Wiki.org From: Jason Swindle greven@jswindle.com Date: Wed, 19 Jan 2005 14:10:04 -0600 To: appdb@winehq.org
Hello,
Can you please add Wine-Wiki.org to the list of Compatibility site. We have been growing greatly, and if it was on the site, it would help everyone.
Thanks ~Jason
Hello,
*My* thoughts about this is if we link to every wiki,tool,help,whatever site out there they should in return link to our Donations site/link.
This is just my opinion :-)
Tom
Hi,
On Thu, Jan 20, 2005 at 09:28:50AM -0500, Tom wrote:
Hello,
*My* thoughts about this is if we link to every wiki,tool,help,whatever site out there they should in return link to our Donations site/link.
This is just my opinion :-)
Wrong, since now it's not only yours anymore ;-)
Andreas Mohr
Can you please add Wine-Wiki.org to the list of Compatibility site. We have been growing greatly, and if it was on the site, it would help everyone.
It seems that Wine-Wiki.org is basically redoing the Application Database and IMHO it's a shame for two reasons: * building and maintaining an application database takes a lot of work and it's a shame to duplicate that work. * users need a clear place to go to when they need information about running their application in Wine. Multiplying places where they can find this information does not help them, it only creates confusion. (due to contradictory and/or out of date information)
Also it's not like the Wine project is not responsive to patches. So I don't see what kind of information would justify creating a separate web site and could not go either directly in the Wine documentation or on the WineHQ's site.
Francois Gouget wrote:
Can you please add Wine-Wiki.org to the list of Compatibility site. We have been growing greatly, and if it was on the site, it would help everyone.
It seems that Wine-Wiki.org is basically redoing the Application Database and IMHO it's a shame for two reasons:
- building and maintaining an application database takes a lot of work
and it's a shame to duplicate that work.
- users need a clear place to go to when they need information about
running their application in Wine. Multiplying places where they can find this information does not help them, it only creates confusion. (due to contradictory and/or out of date information)
Also it's not like the Wine project is not responsive to patches. So I don't see what kind of information would justify creating a separate web site and could not go either directly in the Wine documentation or on the WineHQ's site.
It seems the main reason for these other sites creaping up is that there is or was a deficiency in wine or our web sites.
Franks corner seems to have grown out of the lack of information in the AppDB. This is a very good site but in theory all the information at this site should be available in the AppDB since Frank is an administrator of the AppDB.
It seems that Winetools and Sidenet have grown out of the difficulties or problems configuring Wine. The fact that winecfg is not up to snuff and the documentation on configuring wine is out of date and currently misleading certainly does not help the situation. It seems the users love these tools but I would prefer that they were part of the code base or better yet not nessasary.
I am not sure of the purpose of the wine wiki but from what I have seen it seems to be that it is duplicating "once again" the information that should be in the AppDB or our Documentation.
I am not opposed to these sites. I am just a little sad that they somehow seem to be nessesary.
The bottom line here is that anyone who wants this to be linked can submit a patch.
--
Tony Lambregts
On Sun, 2005-01-23 at 17:28 -0700, tony_lambregts@telusplanet.net wrote:
Francois Gouget wrote:
Can you please add Wine-Wiki.org to the list of Compatibility site. We have been growing greatly, and if it was on the site, it would help everyone.
It seems that Wine-Wiki.org is basically redoing the Application Database and IMHO it's a shame for two reasons:
- building and maintaining an application database takes a lot of work
and it's a shame to duplicate that work.
- users need a clear place to go to when they need information about
running their application in Wine. Multiplying places where they can find this information does not help them, it only creates confusion. (due to contradictory and/or out of date information)
Also it's not like the Wine project is not responsive to patches. So I don't see what kind of information would justify creating a separate web site and could not go either directly in the Wine documentation or on the WineHQ's site.
It seems the main reason for these other sites creaping up is that there is or was a deficiency in wine or our web sites.
Franks corner seems to have grown out of the lack of information in the AppDB. This is a very good site but in theory all the information at this site should be available in the AppDB since Frank is an administrator of the AppDB.
It seems that Winetools and Sidenet have grown out of the difficulties or problems configuring Wine. The fact that winecfg is not up to snuff and the documentation on configuring wine is out of date and currently misleading certainly does not help the situation. It seems the users love these tools but I would prefer that they were part of the code base or better yet not nessasary.
I am not sure of the purpose of the wine wiki but from what I have seen it seems to be that it is duplicating "once again" the information that should be in the AppDB or our Documentation.
I am not opposed to these sites. I am just a little sad that they somehow seem to be nessesary.
The bottom line here is that anyone who wants this to be linked can submit a patch.
--
Tony Lambregts
A Wiki can thrive alongside good documentation. While the documentation is general in nature, the Wiki can explain particular issues for certain users.
A good example would be the distribution specific stuff already in the Wine Wiki - some of that stuff really shouldn't be in the main documentation like the User Guide.
A very good example of this working model in progress is that of Ubuntu Linux itself. They have good documentation, but also a good wiki and user forums.
I brought up the issue of the need for user forums a long time ago (and pointed out that's exactly why forums at Franks Corner had sprouted up). Hopefully we'll get AppDB working to fill most of this niche, although frankly I wouldn't mind having user forums like the Ubuntu ones to replace the mailing list. Posting and browsing threads on forums is a lot easier than combing through a bunch of messages in my inbox, and today's forum software lets you read/post messages by email anyway.
Needless to say, I'll be reading through the wiki to see what can be updated in the documentation as I'm going through it.
As for my thoughts on winetools, see my next email.
-Scott Ritchie
My opinion is that no third party tools/web sites should be needed, at least not for basic stuff. Anybody that posts to a wiki can also add a comment to appdb, or become a maintainer.
Ivan.
On Mon, 2005-01-24 at 01:45 +0100, Ivan Leo Puoti wrote:
My opinion is that no third party tools/web sites should be needed, at least not for basic stuff. Anybody that posts to a wiki can also add a comment to appdb, or become a maintainer.
Ivan.
Frankly it means it's a bit too hard if people choose not to. If people are posting useful information in a wiki or user forums, it means they find it easier to do so.
And people post a LOT in user forums. Unfortunately, they're forums most of us don't see: The Linux gaming forums, the Ubuntu forums, the Something Awful forums - all have the occasional Wine post from a user who can't seem to find the right place to ask for help, since the IRC channel and mailing list just don't quite cut it.
I was one of those users once too. Seriously, we need to make finding help at Wine's page easier. The AppDB stuff is pretty essential, and making it more functional and usable has been a great thing, but we can do more, since people aren't using it.
The interface in AppDB for posting might be a little too cryptic or difficult. Maybe the registration requirement is pushing user's away to the Wiki. Maybe it's hard to find AppDB on the main Wine page (it is just that small little link "applications", afterall, which doesn't say much about anything.) Maybe AppDB's bizarre front page is pushing them away. Maybe it's hard to find the app you need. Maybe it's not clear how easy it is to be a maintainer, or what they do.
I'd like to thank the AppDB hackers a lot, though. It's come a long way rather fast. I'd like to make some changes to make it more readable myself, though, such as cleaning up the front page. But even I got scared away by the lack of template files. Maybe we can start polishing off that todo file :)
Thanks, Scott Ritchie
If the appdb isn't good enough, we should fix it, not link to third party web sites.
Ivan.
On Mon, Jan 24, 2005 at 02:24:48AM +0100, Ivan Leo Puoti wrote:
If the appdb isn't good enough, we should fix it, not link to third party web sites.
The AppDB will never replace a Wiki. They serve different purposes. Trying to shoehorn everything in AppDB is a (big) mistake IMO. We need an official Wiki. I suggest MoinMoin.
On Mon, Jan 24, 2005 at 02:24:48AM +0100, Ivan Leo Puoti wrote:
If the appdb isn't good enough, we should fix it, not link to third party web sites.
Here's something I noticed when I last wanted to find some info in the AppDB. Browsing through the database is really well organized, but what I find a bit confusing was the "Rating with Windows" and "Rating without Windows" graphs in the version-overview of some application. What do 3 or 4 stars there really mean? Do users like this app? use this app? Or does it have to do with how well the app runs under Wine? If so, then why is there a "rating with Windows" at all? Normally you already know/use the app you are looking for, and if not, you'd select an app by how well it runs in wine, right? So either way, you don't really care for a "Rating with Windows" (at least I dont ;-)
What I think what would be more intuitive (at least for the "versions" selection page) would be something like a red, yellow or green background color in the table row, which then means "runs flawlessly", "runs, but with minor problems" or "does not run at all" (and maybe a white background for "untested/unknown") This could also be extended to 2 color boxes: "how well does the installation work" and "how well does the program/game itself work" (and maybe if for example the color is yellow and the problem is fixed recently then show something like "fixed in CVS HEAD" or "will work in next release" etc., although one would need app-maintainers for this kind of task I think)
Just my 2 cents...
--Michael
Le mardi 25 janvier 2005 à 21:13 +0100, Michael Drüing a écrit :
Here's something I noticed when I last wanted to find some info in the AppDB. Browsing through the database is really well organized, but what I find a bit confusing was the "Rating with Windows" and "Rating without Windows" graphs in the version-overview of some application. What do 3 or 4 stars there really mean? Do users like this app? use this app? Or does it have to do with how well the app runs under Wine? If so, then why is there a "rating with Windows" at all? Normally you already know/use the app you are looking for, and if not, you'd select an app by how well it runs in wine, right? So either way, you don't really care for a "Rating with Windows" (at least I dont ;-)
"Rating with Windows" mean rating when using a real windows partition. This rating might have good reasons to be here in the past (when most apps needed many native dlls) but is now regarded as a bad feature by some of AppDB hackers. Maybe some other readers here can say what they think about the removal of this feature ?
What I think what would be more intuitive (at least for the "versions" selection page) would be something like a red, yellow or green background color in the table row, which then means "runs flawlessly", "runs, but with minor problems" or "does not run at all" (and maybe a white background for "untested/unknown") This could also be extended to 2 color boxes: "how well does the installation work" and "how well does the program/game itself work" (and maybe if for example the color is yellow and the problem is fixed recently then show something like "fixed in CVS HEAD" or "will work in next release" etc., although one would need app-maintainers for this kind of task I think)
This already exists (but no color scheme yet). Each app can now be rated Garbage, Bronze, Silver and Gold by a maintainer or administrator. This is a recent feature and is much more clear than "Rating with/without Windows" IMHO. As I maintain many applications in the database, I tried to be consistant in the way I'm describing the compatibility of each application under wine. You can see that the installation part is separated from the running part (see http://appdb.winehq.org/appview.php?appId=1533&versionId=2230 for an example).
What we need yet is to attract more maintainers in order to have accurate data in the AppDB.
On Tue, 25 Jan 2005, Jonathan Ernst wrote: [...]
"Rating with Windows" mean rating when using a real windows partition. This rating might have good reasons to be here in the past (when most apps needed many native dlls) but is now regarded as a bad feature by some of AppDB hackers. Maybe some other readers here can say what they think about the removal of this feature ?
I agree that now the 'Rating with Windows' option is not really useful any more. One of the reasons is that the result is going to be completely different if the Windows is Windows 98 than if it's Windows XP.
So the 'Rating without Windows' should become the only rating. But I like the 0 to 5 rating: 0 -- Unrated. 1 -- Does not work. Totally nonfunctional. Crashes on load. 2 -- Partial functionality. Good enough for a carefully scripted demo. 3 -- Limited functionality. Sufficient functionality for noncritical work. Occasional crashes okay, as are weird setup problems, required patches, or missing major functionality. Alpha quality. 4 -- Usable. Substantially correct. Good enough for general use, with possible caveats. 5 -- Perfect. No flaws under any mode.
The medal system seems redundant and much less precise.
Maybe representing this as stars is not the best way to convey the nuances above. Maybe it's the label that needs changing to better convey the 'How well does it work?' meaning. Maybe 'Works: 80%' would be clearer than 'Rating: 4'. Can we have a tooltip popup (e.g. using an alt property?) when the user moves the mouse over the rating? What about making the rating a link to the section that explains what it means? (the documentation was a bit hard to find, probably because I expected 'Documentation' to point to Wine's documentation)
Maybe text is the best, just use the labels above plus a color code.
Francois Gouget wrote:
On Tue, 25 Jan 2005, Jonathan Ernst wrote: [...]
"Rating with Windows" mean rating when using a real windows partition. This rating might have good reasons to be here in the past (when most apps needed many native dlls) but is now regarded as a bad feature by some of AppDB hackers. Maybe some other readers here can say what they think about the removal of this feature ?
I agree that now the 'Rating with Windows' option is not really useful any more. One of the reasons is that the result is going to be completely different if the Windows is Windows 98 than if it's Windows XP.
The "With Windows" day is gone. We _will_ get rid of it. It is a bad thing since running wine with a real Windows system can be dangerous to the real Windows setup.
So the 'Rating without Windows' should become the only rating. But I like the 0 to 5 rating: 0 -- Unrated. 1 -- Does not work. Totally nonfunctional. Crashes on load. 2 -- Partial functionality. Good enough for a carefully scripted demo. 3 -- Limited functionality. Sufficient functionality for noncritical work. Occasional crashes okay, as are weird setup problems, required patches, or missing major functionality. Alpha quality. 4 -- Usable. Substantially correct. Good enough for general use, with possible caveats. 5 -- Perfect. No flaws under any mode.
The medal system seems redundant and much less precise.
How is that really different than this.
http://appdb.winehq.org/help/?topic=maintainer_ratings
The Maintainer rating system is meant for "supported" applications. The terms gold and silver are what were already there and are similar to what CodeWeavers uses. If you would like to refine those definitions feel free to submit a patch.
Maybe representing this as stars is not the best way to convey the nuances above. Maybe it's the label that needs changing to better convey the 'How well does it work?' meaning. Maybe 'Works: 80%' would be clearer than 'Rating: 4'. Can we have a tooltip popup (e.g. using an alt property?) when the user moves the mouse over the rating? What about making the rating a link to the section that explains what it means? (the documentation was a bit hard to find, probably because I expected 'Documentation' to point to Wine's documentation)
Maybe text is the best, just use the labels above plus a color code.
The "star" rating system definately needs to be revamped. It is on the TODO list. however it serves as a different purpose than the Maintainer ratings since it is for regular users. We should/will revamp the documentation for it at the same time.
These discussions are important feedback to improving the AppDB, so thank you for your thoughts.
--
Tony Lambregts
On Wed, 26 Jan 2005 tony_lambregts@telusplanet.net wrote: [...]
How is that really different than this.
http://appdb.winehq.org/help/?topic=maintainer_ratings
The Maintainer rating system is meant for "supported" applications.
That's the thing. There is no such thing as a 'supported application' in Wine, at least the way I understand 'supported': * there is no garantee a 'supported' application will continue to work in the next version of Wine. That's because Alexandre does not try each 'supported' application to make sure it still works before making a release.
* there's no Wine hacker to fix a 'supported' application if it breaks. Having an application maintainer for each 'supported' application is important and a first step towards making sure it will continue to work. But it's not sufficient. If it breaks it will need a Wine developer to look into it and debug it and I don't see any one proposing to do it or able to garantee this.
* There's no garantee that a Gold application will not regress to Silver, Bronze or even lower.
* And finally I don't see any Wine hacker proposing any specific 'support' for the 'supported' applications.
So these 'supported' applications are no different from any other application and the medals mean nothing more than the old rating system. They just have 4 levels instead of 6.
The terms gold and silver are what were already there and are similar to what CodeWeavers uses.
The terms are similar but the AppDB medals provide none of the garantees that the CodeWeavers' medals provide.
If you would like to refine those definitions feel free to submit a patch.
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
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.
[...]
These discussions are important feedback to improving the AppDB, so thank you for your thoughts.
Yes, I am very thankful for all the work people have been putting in the Application Database lately. I think the Application Database is an important piece of WineHQ and it's fantastic to see it get some love and attention at last.
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
On the other hand: some applications don't install but do run, after you installed them manually.
Robert
Francois Gouget wrote:
On Wed, 26 Jan 2005 tony_lambregts@telusplanet.net wrote: [...]
How is that really different than this.
http://appdb.winehq.org/help/?topic=maintainer_ratings
The Maintainer rating system is meant for "supported" applications.
That's the thing. There is no such thing as a 'supported application' in Wine, at least the way I understand 'supported':
- there is no garantee a 'supported' application will continue to work
in the next version of Wine. That's because Alexandre does not try each 'supported' application to make sure it still works before making a release.
- there's no Wine hacker to fix a 'supported' application if it breaks.
Having an application maintainer for each 'supported' application is important and a first step towards making sure it will continue to work. But it's not sufficient. If it breaks it will need a Wine developer to look into it and debug it and I don't see any one proposing to do it or able to garantee this.
- There's no garantee that a Gold application will not regress to
Silver, Bronze or even lower.
- And finally I don't see any Wine hacker proposing any specific
'support' for the 'supported' applications.
So these 'supported' applications are no different from any other application and the medals mean nothing more than the old rating system. They just have 4 levels instead of 6.
As far as things go until we go to a "Stable release" system then we will always have this problem. 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". 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.
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.
The terms gold and silver are what were already there and are similar to what CodeWeavers uses.
The terms are similar but the AppDB medals provide none of the garantees that the CodeWeavers' medals provide.
To quote CodeWeavers website.
"CrossOver Office only officially supports about a dozen applications. However, the truth is that CrossOver runs many Windows applications quite well,"
http://www.codeweavers.com/site/compatibility/
CodeWeavers does not make any guarantee that just because one version of a program is supported the next will be (ie Microsoft Word). So if we had a stable release cycle and CodeWeavers does not change their official support policy. They approach the same meaning.
One other thing I sould say is that: There _is_ (or at least should be) a difference in expectation between "Paid for Support" and "Free Support"
If you would like to refine those definitions feel free to submit a patch.
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 ....
There is no way around the fact that if a program is not "Gold" or "Perfect" you need a at least a HOWTO.
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.)
[...]
These discussions are important feedback to improving the AppDB, so thank you for your thoughts.
Yes, I am very thankful for all the work people have been putting in the Application Database lately. I think the Application Database is an important piece of WineHQ and it's fantastic to see it get some love and attention at last.
We try..
--
Tony Lambregts
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.
Francois Gouget wrote:
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.
Thats BS. (pardon me) :^) That is circular reasoning. What I am hearing is we shouldn't define the criteria for "stable" because we aren't stable. We could go "stable" today if we wanted and this is how:
Instead of Alexandre simply saying "today" I am going to release, we do the following:
- Alexandre makes an announcement that CVS is in freeze.
- Maintainers of current "Gold" apps find regressions.
- Maintainers report the patchs that broke the applications.
- We fix the regressions and they are all fixed we release.
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.
How's that? The way it works now is that if someone reports on Wine Devel that patch X breaks their application the developer of the patch usually will step up with a fix, often it is the same day. I cannot see how this is in any way presumptuous. It simply flows from the way we work today.
IMHO it's best to focus on the now and do stuff that makes sense now.
Having maintainers of apps makes sense in its own right.
In a way it's just a wording issue, I would not be opposed to the notion of 'maintained applications'.
If its just semantics then fine. I did not come up with the term. IIRC it was Dimi. We can change it if it really matters to you.
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.
All that users care is that their application works. We need a structured way of defining what works and what does not. The application database without maintainers could not give us that. I would not have spent as much time on it if I thought we could do it any other way.
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.
IIRC Its part of the sign screen up. We probably should get it such a document when it is written.
[...]
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).
exactly
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.
Same circular reasoning. see first comment.
[...]
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).
If copying DLL's is OK for you why not Copying programs. Also Hacks can lead to good patches and don't tell you have never used a hack to get the job done. AFAIAC "Perfect" means you can run it out of the box with no tweeking. There are apps like that and I see no reason to make it less clear to the user or maintainer.
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.
These are good for the developer but the focus of the AppDB is on the user. This is where Bugzilla comes into the picture. I am working on a patch to better integrate these two applications. I was planning on working on it tonight but instead ended up responding to this. ;^)
- 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.
Apps like this are Bronze and need the resources of Bugzilla to deal with them.
- Perfect The application is fully usable.
That's all that matters to users.
Those are Gold and Silver.
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.
An application that requires native DLLs is not "Perfect" since I should not need a windows licence to run Windows applications. (Yes it is harsh but we are kidding ourselves otherwise.)
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.
We are not too far apart. I was just going with the flow when I implemented the maintainer rating system. Gold and silver apps were already defined and it seemed appropriate to follow that with bronze to include apps that are "Usable" and "Garbage" for those that are seriously broke. I talked extensively on IRC about this with Chris Morgan and others before implementing it. I admit it is not perfect but as I have said before. Any rating system sucks by definition.
--
Tony Lambregts
On Wed, 26 Jan 2005, Tony Lambregts wrote:
Francois Gouget wrote:
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.
Thats BS. (pardon me) :^) That is circular reasoning. What I am hearing is we shouldn't define the criteria for "stable" because we aren't stable. We could go "stable" today if we wanted and this is how:
I'm not saying we cannot define the criteria, I'm saying it does not make sense to work and make promises today that will only make sense when we have stable releases which could be years away (if following historical trends).
And no, we cannot make 'stable' releases today. Some of the criteria for 0.9 are: completing the window management rewrite, good enough dll separation and stabilizing the wineserver protocol. We're close on some of these goals but there's still work. And as far as I know there won't be stable releases before we reach 0.9.
[...]
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.
How's that? The way it works now is that if someone reports on Wine Devel that patch X breaks their application the developer of the patch usually will step up with a fix, often it is the same day. I cannot see how this is in any way presumptuous. It simply flows from the way we work today.
I can tell you that there are a lot of regressions that slip through and are only detected much later and that give us (CodeWeavers) quite a lot of work before doing a release. Hopefully the situation will be much better once cxtest is in 'full production' and Wine has more maintainers.
IMHO it's best to focus on the now and do stuff that makes sense now.
Having maintainers of apps makes sense in its own right.
Yes, I agree absolutely there.
[...]
This should really go in a "Maintainer's Guide" somewhere.
IIRC Its part of the sign screen up. We probably should get it such a document when it is written.
I did not see it on this page: http://appdb.winehq.org/account.php?cmd=new
I'd expect to see it somewhere in the 'Documentation' pages: http://appdb.winehq.org/help/
[...]
If copying DLL's is OK for you why not Copying programs.
Because copying programs usually require copying parts of the Windows registry which I think is just way too complex for a regular user.
Usually copying a dll doesn't require anything more than copying a file, sometimes not even that as the dll may have already been installed by the application and all you need is to tell Wine to use it instead of the builtin.
Also Hacks can lead to good patches and don't tell you have never used a hack to get the job done. AFAIAC "Perfect" means you can run it out of the box with no tweeking.
Yes, we could have a 'Works great' for apps running great with hacks and limit 'Perfect' to the applications that run great with only builtin dlls and no 'abnormal' dependencies.
[...]
- 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.
These are good for the developer but the focus of the AppDB is on the user. This is where Bugzilla comes into the picture. I am working on a patch to better integrate these two applications. I was planning on working on it tonight but instead ended up responding to this. ;^)
The AppDB should be useful to Wine developers too.
Francois Gouget wrote:
On Wed, 26 Jan 2005, Tony Lambregts wrote:
Francois Gouget wrote:
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.
Thats BS. (pardon me) :^) That is circular reasoning. What I am hearing is we shouldn't define the criteria for "stable" because we aren't stable. We could go "stable" today if we wanted and this is how:
I'm not saying we cannot define the criteria, I'm saying it does not make sense to work and make promises today that will only make sense when we have stable releases which could be years away (if following historical trends).
And no, we cannot make 'stable' releases today. Some of the criteria for 0.9 are: completing the window management rewrite, good enough dll separation and stabilizing the wineserver protocol. We're close on some of these goals but there's still work. And as far as I know there won't be stable releases before we reach 0.9.
That's again circular. One of the things that need to be in place for 0.9 is a stable release cycle.
I would like to ask for the following baby step instead: Alexandre gives a "heads up notice" couple of days before he actualy releases.
This would give maintainers a last a chance to find regressions before we release. No promises no gaurantees. just a small change in the way we do things.
I talked to Alexandre on ICR and in the end he said: "Prove to me that we can do meaningful regression testing and then we'll see about improving the sheduling"
So it's not just you. :(
I could cry.
Which of these more resonable entry for the "Maintainers Guide"? ... Testing:
Since we do not have a stable release cycle Maintainers should compile from CVS and test as often as possible, at least every week. If you find a regression please try to identify the patch through regression testing. Once you have found the patch please report it on wine-devel@winehq.org. hopefully the developer that created the patch (or someone else) will come forward and propose a fix. There is no gaurantee that anyone will help you fix the regression but they usually do.
Snapshots released roughly once a month but there is no way to know for sure when a snapshot will be released. Early detection of regressions increase the chance of fixing them, so please test often. ... or this. ... Testing:
Since we do not have a stable release cycle Maintainers should compile from CVS and test as often as possible, at least every week. If you find a regression please try to identify the patch through regression testing. Once you have found the patch please report it on wine-devel@winehq.org. hopefully the developer that created the patch (or someone else) will come forward and propose a fix. There is no gaurantee that anyone will help you fix the regression but they usually do.
Snapshots are released roughly once a month but Alexandre will announce that we will be releasing a snapshot in a couple of days. This is the last chance for us to find regressions before a release. We really do not want to be flooding the mailing list with regressions from weeks past at this point. Early detection of regressions increase the chance of fixing them, so please test often. ...
[...]
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.
How's that? The way it works now is that if someone reports on Wine Devel that patch X breaks their application the developer of the patch usually will step up with a fix, often it is the same day. I cannot see how this is in any way presumptuous. It simply flows from the way we work today.
I can tell you that there are a lot of regressions that slip through and are only detected much later and that give us (CodeWeavers) quite a lot of work before doing a release. Hopefully the situation will be much better once cxtest is in 'full production' and Wine has more maintainers.
Yes. But that is true of any software. Right now there wine has no quality assurance. Hopefully with more maintainers we can get there but just having more maintainer by itself is not enough.
[snip]
If copying DLL's is OK for you why not Copying programs.
Because copying programs usually require copying parts of the Windows registry which I think is just way too complex for a regular user.
Not all applications require the registry. I know of a couple that work fine that way.
Usually copying a dll doesn't require anything more than copying a file, sometimes not even that as the dll may have already been installed by the application and all you need is to tell Wine to use it instead of the builtin.
I can see this if it comes with the application but if I don't have a licence for windows (or the right version of windows) I cannot do this.
You want Gold to be more inclusive and I want it to be exclusive. Anyone should be able to run a "gold" (regardless of their windows licence). I can sympatize with wanting more apps to be gold but fudging things to get there is not the way.
[Snip]
--
Tony Lambregts
I talked to Alexandre on ICR and in the end he said: "Prove to me that we can do meaningful regression testing and then we'll see about improving the sheduling"
So it's not just you. :(
Well, I agree with AJ there...
I would not change our release cycle as long as there is no proof that the 'maintainer doing regression testing' system works. If you can prove that at least x % (x to be determined :-) ) of our maintainers take the time to do a regression at least for each Wine release, then it will be time to change to have 'stabler' releases.
If not, why change the system if it won't be used ?
Lionel
On Thu, 27 Jan 2005 tony_lambregts@telusplanet.net wrote: [...]
And no, we cannot make 'stable' releases today. Some of the criteria for 0.9 are: completing the window management rewrite, good enough dll separation and stabilizing the wineserver protocol. We're close on some of these goals but there's still work. And as far as I know there won't be stable releases before we reach 0.9.
That's again circular. One of the things that need to be in place for 0.9 is a stable release cycle.
No you have it reversed. There's no point to put in place a complex release cycle if the code itself is not somwehat stable (i.e. we don't rewrite core subsystems anymore).
So first we must make the code stable and that's what 0.9 is about. Once we have stabilized the core code and architecture of Wine we can think about putting into place procedures for making a new Wine release.
Which of these more resonable entry for the "Maintainers Guide"?
Neither. Here's a rough draft.
--- cut here ---
What are the tasks of an application maintainer?
* Give a short description of the application.
This is not the most important task but it's still good to describe what the application does. This description should be short and ideally you would accompany it with screenshots of the application running in Wine (assuming it does run in Wine).
* Find the best way to install and run the application.
The application may not work or even install the first time you try it. Don't give up just yet. Try the tricks described there <link to document describing how to install and run apps>. The goal here is to get the application working as best as possible by tweaking the Wine environment.
* Restart from scratch and optimize your setup.
Once you have found some settings that seem to work, wipe out your .wine directory and start over. This is so you can verify that the result you obtained is reproducible and that you did not forget some steps or configuration tweaks. Also, this time try to only use application-specific settings for dll overrides and such. This is important to minimize the conflicts between applications.
* Describe how to install and run the application.
Hopefully you kept notes while working on the previous task because now you will have to describe what you have done. Configuring Wine so an application runs well is hard, there are a lot of options and combinations to try and most Wine users won't have the time or patience to go through it all. This is why this task is probably the most important: it lets the other Wine users benefit from your hard earned experience in running this application as best as possible. So describe carefully the Wine configuration options to use. Don't hesitate to include the relevant configuration file snippets, especially those application specific sections which users can just drop in at the end of their configuration file. Also, don't forget to mention any pre-requisites to installing the application such as installing Internet Explorer or other software the application depends upon. Finally you may want to provide the command line to use to start the application as this is not always obvious, especially if the application needs a specific working directory.
* Describe what works and what does not.
Potential users of this application will want to know which features are usable and which are not. It is only armed with this information that they will be able to determine whether the application is usable for them or not. Of course if the application does not work this will be simple. If the application does work, then try to exercise its various modules like: opening and saving files, importing and exporting files, printing, the print preview mode, etc. If there is an area that you were not able to test (e.g. printing because you have no printer), mention it too.
* Rate the application.
Rate the application as described there <link to the ratings guidelines>. The work you did in the above step will come in handy to determine the appropriate rating.
* Report the problems.
If in the above steps you have identified reproducible issues, report them in Bugzilla as described there <link to the bug reporting howto>.
* Test the application on a regular basis.
Ideally you would test it once a week so that you can quickly notify the Wine developers of any regression. The earlier a Wine regression is noticed, the easier it will be to locate the change that causing it and the more likely it is to be fixed. At the very least you should test the application with each Wine release. If you detect a regression at that point it is likely you will have to go through regression testing to identify the patch causing the problem. Also mention any stability problem.
* Help users who have trouble getting the application to work as well as you.
People will want to follow in your footsteps but some may stumble along the way. Try to work out with them why stuff that works for you does not work for them. Maybe they changed a global Wine setting that interfers with your application. Maybe that global Wine setting is needed to run another application. Try to see if there's a way to get both applications working. This includes monitoring the application forum to make sure it remains on topic and to remove obsolete information.
While these steps are given in a seemingly logical order, you will probably have to iterate a bit, especially between the application testing and configuration tweaking steps.
--- cut here ---
Francois Gouget wrote: [Snip]
Test the application on a regular basis.
Ideally you would test it once a week so that you can quickly notify
the Wine developers of any regression. The earlier a Wine regression is noticed, the easier it will be to locate the change that causing it and the more likely it is to be fixed. At the very least you should test the application with each Wine release. If you detect a regression at that point it is likely you will have to go through regression testing to identify the patch causing the problem. Also mention any stability problem.
I thought I was :-)
So instead of answering the question you avoid the question entirly.
Shame on you.
--
Tony Lambregts
On Thu, 27 Jan 2005 tony_lambregts@telusplanet.net wrote:
Francois Gouget wrote: [Snip]
Test the application on a regular basis.
Ideally you would test it once a week so that you can quickly notify the
Wine developers of any regression. The earlier a Wine regression is noticed, the easier it will be to locate the change that causing it and the more likely it is to be fixed. At the very least you should test the application with each Wine release. If you detect a regression at that point it is likely you will have to go through regression testing to identify the patch causing the problem. Also mention any stability problem.
I thought I was :-)
No, I'm not talking about your concept of stability here. Maybe you realised that but just in case to make things clear, here I'm asking the maintainer to mention in his report whether the application tends to crash or freeze seemingly randomly (if it's a specific action that causes trouble it would go in the list of things that don't work).
So instead of answering the question you avoid the question entirly.
Wine's release cycle is simply irrelevant to the Application Maintainer's Guide.
Francois Gouget wrote:
On Thu, 27 Jan 2005 tony_lambregts@telusplanet.net wrote:
Wine's release cycle is simply irrelevant to the Application Maintainer's Guide.
No, it is not important to you. To me its about what is resonable to ask a maintainer to do. At some point in time we will be stable and we will need these guys to ensure that their application works from one release to the next. In anticipation of that time I tried to see what we could do today.
I know that your responce is going to go something like this. So I will stop banging my head for now.
--
Tony Lambregts
Francois Gouget wrote:
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.
Francois Gouget wrote:
On Wed, 26 Jan 2005 tony_lambregts@telusplanet.net wrote: [...]
How is that really different than this.
http://appdb.winehq.org/help/?topic=maintainer_ratings
The Maintainer rating system is meant for "supported" applications.
That's the thing. There is no such thing as a 'supported application' in Wine, at least the way I understand 'supported':
- there is no garantee a 'supported' application will continue to work
in the next version of Wine. That's because Alexandre does not try each 'supported' application to make sure it still works before making a release.
- there's no Wine hacker to fix a 'supported' application if it breaks.
Having an application maintainer for each 'supported' application is important and a first step towards making sure it will continue to work. But it's not sufficient. If it breaks it will need a Wine developer to look into it and debug it and I don't see any one proposing to do it or able to garantee this.
- There's no garantee that a Gold application will not regress to
Silver, Bronze or even lower.
- And finally I don't see any Wine hacker proposing any specific
'support' for the 'supported' applications.
So these 'supported' applications are no different from any other application and the medals mean nothing more than the old rating system. They just have 4 levels instead of 6.
I think having more than 3-4 levels is too much by the way; it's much too hard to rate an application in such small quality steps.
As for application that could regress from gold to another rating, I think that's not a problem as when a maintainer rates an application he states what version of Wine he was using (next drop down box after the maintainer rating).
I even started to track an history of application ratings for the apps I maintain: each time I retest an application I update the application rating AND the history table so that someone can figure out that an application was working better with an older wine release.
See here for examples: http://appdb.winehq.org/appview.php?appId=1533&versionId=2230 http://appdb.winehq.org/appview.php?appId=2&versionId=764
Maybe we could add a feature that'll keep track of maintainer rating automatically and produce an history table like the one I'm adding to the application version descriptions automatically.
Le jeudi 27 janvier 2005 à 00:00 +0100, Francois Gouget a écrit :
If it was up to me I would eliminate the the user rating. (But thats me.)
I would not be strongly opposed to this.
I would eliminate this rating too (both with/without windows).
Am Donnerstag, 27. Januar 2005 10:30 schrieb Jonathan Ernst: <big snip>
So these 'supported' applications are no different from any other application and the medals mean nothing more than the old rating system. They just have 4 levels instead of 6.
I think having more than 3-4 levels is too much by the way; it's much too hard to rate an application in such small quality steps.
maybe it is a good idea to seperate the installation rating from how well the program runs. I often had problems to install apps that run perfectly if you get past the installer ;-). just my 2 cents ...
As for application that could regress from gold to another rating, I think that's not a problem as when a maintainer rates an application he states what version of Wine he was using (next drop down box after the maintainer rating).
I even started to track an history of application ratings for the apps I maintain: each time I retest an application I update the application rating AND the history table so that someone can figure out that an application was working better with an older wine release.
See here for examples: http://appdb.winehq.org/appview.php?appId=1533&versionId=2230 http://appdb.winehq.org/appview.php?appId=2&versionId=764
that's a very good idea and i think the rating system in general should be linked to a wine version otherwise it's relatively useless. I always read the comments to figure out wether the (hopefully good ;-) rating of an app maybe is based on a wine version from 2001.
cu,
Stefan
On Tue, 2005-01-25 at 22:28 +0100, Jonathan Ernst wrote:
Le mardi 25 janvier 2005 à 21:13 +0100, Michael Drüing a écrit :
Here's something I noticed when I last wanted to find some info in the AppDB. Browsing through the database is really well organized, but what I find a bit confusing was the "Rating with Windows" and "Rating without Windows" graphs in the version-overview of some application. What do 3 or 4 stars there really mean? Do users like this app? use this app? Or does it have to do with how well the app runs under Wine? If so, then why is there a "rating with Windows" at all? Normally you already know/use the app you are looking for, and if not, you'd select an app by how well it runs in wine, right? So either way, you don't really care for a "Rating with Windows" (at least I dont ;-)
"Rating with Windows" mean rating when using a real windows partition. This rating might have good reasons to be here in the past (when most apps needed many native dlls) but is now regarded as a bad feature by some of AppDB hackers. Maybe some other readers here can say what they think about the removal of this feature ?
It should be removed, and if we are going to replace it, it should be "rating with custom DLLs" or something like that. That way we can indicate if it requires something like native DCOM to run.
Also, I eagerly anticipate the maintainer ratings patches, as those will be much more important for getting useful information about how well a program works than the voting.
-Scott Ritchie
On Tue, 25 Jan 2005, Scott Ritchie wrote: [...]
Also, I eagerly anticipate the maintainer ratings patches, as those will be much more important for getting useful information about how well a program works than the voting.
AFAIU the votes are not meant to carry any information about how well an application works. Maybe you meant that about the regular rating?
Also I think the AppDB needs a maintainer's guide that would describe the tasks of a maintainer and an AppDB entry that could be used as a reference. For now I'd say that the Visual FoxPro entry could be used as a reference: http://appdb.winehq.org/appview.php?appId=296
My only nitpick with the FoxPro entry is that it should recommend using an application specific entry for the DLL Overrides (and show how to do that). That's because there's no garantee that all applications are going to work better with the native oleaut32.dll, etc.
Francois Gouget wrote:
On Tue, 25 Jan 2005, Scott Ritchie wrote: [...]
Also, I eagerly anticipate the maintainer ratings patches, as those will be much more important for getting useful information about how well a program works than the voting.
AFAIU the votes are not meant to carry any information about how well an application works. Maybe you meant that about the regular rating?
Also I think the AppDB needs a maintainer's guide that would describe the tasks of a maintainer and an AppDB entry that could be used as a reference. For now I'd say that the Visual FoxPro entry could be used as a reference: http://appdb.winehq.org/appview.php?appId=296
My only nitpick with the FoxPro entry is that it should recommend using an application specific entry for the DLL Overrides (and show how to do that). That's because there's no garantee that all applications are going to work better with the native oleaut32.dll, etc.
Yes this is a very good entry. To bad it is not a maintained app :-(
--
Tony Lambregts.
Scott Ritchie wrote:
On Tue, 2005-01-25 at 22:28 +0100, Jonathan Ernst wrote:
Le mardi 25 janvier 2005 à 21:13 +0100, Michael Drüing a écrit :
Here's something I noticed when I last wanted to find some info in the AppDB. Browsing through the database is really well organized, but what I find a bit confusing was the "Rating with Windows" and "Rating without Windows" graphs in the version-overview of some application. What do 3 or 4 stars there really mean? Do users like this app? use this app? Or does it have to do with how well the app runs under Wine? If so, then why is there a "rating with Windows" at all? Normally you already know/use the app you are looking for, and if not, you'd select an app by how well it runs in wine, right? So either way, you don't really care for a "Rating with Windows" (at least I dont ;-)
"Rating with Windows" mean rating when using a real windows partition. This rating might have good reasons to be here in the past (when most apps needed many native dlls) but is now regarded as a bad feature by some of AppDB hackers. Maybe some other readers here can say what they think about the removal of this feature ?
It should be removed, and if we are going to replace it, it should be "rating with custom DLLs" or something like that. That way we can indicate if it requires something like native DCOM to run.
That is an idea. hum..
Also, I eagerly anticipate the maintainer ratings patches, as those will be much more important for getting useful information about how well a program works than the voting.
The maintainer rating system is in place already. Only the index page (Supported Apps) remains to be redone and I personally would like to see maintainers for the remaining apps there before we change it. What else is missing that you are you looking foward to?
--
Tony Lambregts
-
Andreas Mohr -
Dimitrie O. Paun -
Francois Gouget -
Ivan Leo Puoti -
Jonathan Ernst -
Lionel Ulmer -
Michael Drüing -
Robert van Herk -
Scott Ritchie -
Stefan Munz -
Tom -
Tony Lambregts -
tony_lambregts＠telusplanet.net