ReactOS 'Support Database' for the new ReactOS Homepage
I wrote down a lot of ideas, questions, soulutions, goals, etc. for the upcoming Support Database! We need more ideas, suggestions, comments, etc! Please read the whole text and then write an email to the mailing list! This text should start discussion about that topic !!!
Thanks!
Note:
* some of the ideas are not completely new, i copy&paste the from winehq's newsletter archive (i quoted the winehq's ideas and add the original post date)!
* I have added some useful links at the of the text! Please try out the links and explore the compatibility databases from other projects! You will need it if you want to join the discussion. And I *hope* a lot of persons join the discussion! So please visite the links and write down what could be better or what's key features our database also should *clone*!
The 'Support Database' will contain the following 'databases':
* Compatibility Database (application, driver and hardware) * Package Database (a list of download-able applications/driver; principal for the ReactOS Package Manager) (* Media Database (like the ReactOS Fansite Media Database; maybe we can implement this later))
The 'Support Database' (project codename 'RosDB') will base on the package manager alpha page that i have created april 2005.
Note: the package database will be combined with the compatibility datbase. Both 'databases' will share the same 'application tree'! So it will be easy e.g. you browse the compatibility db, you found a working app and think, "i also want to download this app", then you will be able to click on a link (on a central position) and you will be redirected to the package database. In near future it should be possible (if you run ReactOS or Win32 with installed and runing ReactOS Package Manager), that you can select your favorite apps/driver you want to install (navigation like amazone/ebay/compatibility db) and then click install (a normal link on the package manager page) and your running (maybe as a service) ReactOS Package Manager check/capture every clipboard item and if it is a valid 'package style link' then it will connect to the online database and download all the selected apps/driver and download it from mirror server (from their developers/sourceforge/etc.) and then install all items (without or with minimum of user interaction). In my (frik85) opinion, that would be one of the 'hottest' feature someone can imagine (in connection with a homepage, package manager, etc.). This feature will became a main feature and everyone will use that *hope* for ReactOs and also possible for Win32 (from MS). :) -- frik85
"ReactOS Compatibility Database ReactOS has an Compatibility Database where Windows application/driver/hardware compatibility is recorded. Registered users can submit new items, and comment on existing ones. Screen shots are also available for many apps. Users can also vote on their favorite apps." -- a possible description
Design goals User wants to know following things:
* Does my application/driver/hardware work? * How can I make it work? * Does it work in the new ReactOS/application/driver/hardware version? * Where can i download the application (maybe with the ReactOS Package Manager)?
* list all working and non working application/driver/hardware
Management Issues/Goals:
We need a high 'input data quality', then the administration work will be a minimum. To reach this high data quality, i want to code a simple to use wizard for the 'submit item' page. You can view the sample wizard on the package manager alpha page (see link).
Have some form of a moderation system to let end users know the quality of a given persons entry. Maybe like the appDB from winehq? Where a registered user can ask for a kind of moderator right for one specific item (e.g. application), so he can manage the comments, add new info, etc. -> taking ownership of an item (e.g. application): monitor comments on it, track bugs (close bugs), and make sure quality level is high for application description.
NO redundant entries for the same product! We need moderators who review all new entries. The moderators should be able to read as many comments as possible and help the normal users, report bugs to the bugzilla system, etc.
Reviews (aka user comments) should expire. (expire time 1 year?)
Track hit counts on each item (auto magic way of knowing which apps are most desired) and maybe voting like in appDB (WineHQ) or in C4 (CodeWeaver).
Some ideas i found in old winehq's neewsletters: (maybe useful for our project!)
"Idea: Tie the apps database to the api database. The idea is that we know from the apps database which apps are the most popular. We know from the api database which DLLs/entry points are used by those apps. We can then create a report out of the api database of the list of the DLLs most needed by the top ten apps, and then people writing test scripts (something Alexandre and John Sturtz are working on), have a prioritized todo list. Again, this helps us find useful things for the many volunteers to do." -- winehq newsletter from 18 Oct 2000
Note: maybe a good idea to create such a api database; -> a simalar api status output is currently generated from the svn server (with a small console based application, see build tools). You can view the api status on the svn server. A great chance to import the data to the database and make the idea above possible! The only question, is it usefull for someone? -- frik85
"Idea: Tie the apps database to bugzilla. If users have a problem with an app, it's a bug, and should be in bugzilla. If we can get to a point where we can easily get a report that says 'here are all the bugs that Quicken depends on'. Or, here are the five bugs, the fixing of which will make 50 apps suddenly work. This would be wicked cool." -- winehq newsletter from 18 Oct 2000
Note: the bugzilla will be a subsystem of the RosCMS, so it will be (maybe) possible to implement the idea above. Is something like this usefull for someone? -- frik85
"if we add some 'relay statistics' in Wine code (of course, there will be problems with COM objects where relaying does not work for now) and incorporate these statistics in the database, we could have a list of the most frequently used Windows calls. (feel free to add new ideas for improvements :-) )" -- winehq newsletter from 28 Dec 2000
"He [who take ownership of an item] definitely should have the application installed and, very preferably, he should also be using it regularly (or testing it regularly if it is not yet in the usable state). You are right in pointing out that he cannot test all possible but I contend he does not have to. His role would be to: read the comments entered in the application's comment section. engage into a discussion with the users who post interesting tricks, information, report a sub-version as not working, report problems with a specific Wine/Windows combination extract and summarize the above in his application status report. This section would come first in the application's page and only the application maintainer would be allowed to modify it (whether it's strictly enforced or not is another issue) test the application regularly and update the information on the application's page help users having problems with that application " -- winehq newsletter from 28 Dec 2000
"Jeremy White proposed some scheme to help keeping the database usable: I think the biggest problem with the app database is that we get garbage in, it produces garbage out. I think we should not report or even use any user scores until a trusted app db maintainer has validated that user experience (and possibly users can become trusted reporters). Too many people say 'Hey! The main screen came up! That's a 5! Witness the Slashdot post about MS Office 2k. (anyone actually try to use Office 2K in Wine to author a sizable document?)." -- winehq newsletter from 28 Dec 2000
The information we will gain from the support database
* the progress of ReactOS (for devs and normal user) * the most wanted applications (when we implement a voting / hit counts feature) * a reference for application/driver/hardware that doesn't work without tweaking, to get them working * people may be able taking 'ownership' of an application and do regular bug reports / regression testings).
Several questions, where we need a answer:
"How to 'classify' applications ?: the main point was how an application should be identified (think of Word 5 vs. WinWord 5 cs. Word 7.0, and lots of other quirks (limited versions, demo version, patched versions...) What information should we have about an application ?: this would help in knowing the correct context of execution of such an application (target Windows version, used DLLs, used APIs...)" -- winehq newsletter from 28 Dec 2000
* And about a ReactOS releases ? * How about scoring ? * What additional information should one application/driver/hardware have?
We need as much ideas, (feedback after the relaunch/while the testing phase), comments, (and flames) as possible the next weeks. After the website relaunch We need volunteers to take responsibility for updating Apps in the Compatibility Database.
We need to discuss this!
Then after the discussions ... only remains the hours of coding and debugging to put it in place :)
Compatibility Databases from other projects:
http://appdb.winehq.org/ http://www.codeweavers.com/compatibility/ http://www.linuxcompatible.org/compatibility.html http://www.ntcompatible.com/compatibility.html
http://www.microsoft.com/whdc/hcl/default.mspx ttp://www.realtimesoft.com/multimon/search.asp http://hardwaredb.suse.de/index.php?LANG=en_UK http://www.testingstandards.co.uk/compatibility_-_database.htm http://www.yellowtab.com/support/hardware/ http://www.iyonix.com/software/ http://www.ardi.com/compat_search.php?name=ALL&category=ALL&status=A...
A kind of Package Database: http://rpmseek.com/index.html?hl=en
If you know other websites that should be listed here, please write an email to the mailing list!
Best regards, Klemens Friedl <frik85>
PS: if you write a comment, do NOT quote whole passages or do NOT quote the whole text! The reason, emails should be readable ...
SkyOS also has a good example.
On 8/23/05, Klemens Friedl klemens_friedl@gmx.net wrote:
ReactOS 'Support Database' for the new ReactOS Homepage
I wrote down a lot of ideas, questions, soulutions, goals, etc. for the upcoming Support Database! We need more ideas, suggestions, comments, etc! Please read the whole text and then write an email to the mailing list! This text should start discussion about that topic !!!
Thanks!
Note:
- some of the ideas are not completely new, i copy&paste the from winehq's
newsletter archive (i quoted the winehq's ideas and add the original post date)!
- I have added some useful links at the of the text! Please try out the
links and explore the compatibility databases from other projects! You will need it if you want to join the discussion. And I *hope* a lot of persons join the discussion! So please visite the links and write down what could be better or what's key features our database also should *clone*!
The 'Support Database' will contain the following 'databases':
- Compatibility Database (application, driver and hardware)
- Package Database (a list of download-able applications/driver; principal
for the ReactOS Package Manager) (* Media Database (like the ReactOS Fansite Media Database; maybe we can implement this later))
The 'Support Database' (project codename 'RosDB') will base on the package manager alpha page that i have created april 2005.
Note: the package database will be combined with the compatibility datbase. Both 'databases' will share the same 'application tree'! So it will be easy e.g. you browse the compatibility db, you found a working app and think, "i also want to download this app", then you will be able to click on a link (on a central position) and you will be redirected to the package database. In near future it should be possible (if you run ReactOS or Win32 with installed and runing ReactOS Package Manager), that you can select your favorite apps/driver you want to install (navigation like amazone/ebay/compatibility db) and then click install (a normal link on the package manager page) and your running (maybe as a service) ReactOS Package Manager check/capture every clipboard item and if it is a valid 'package style link' then it will connect to the online database and download all the selected apps/driver and download it from mirror server (from their developers/sourceforge/etc.) and then install all items (without or with minimum of user interaction). In my (frik85) opinion, that would be one of the 'hottest' feature someone can imagine (in connection with a homepage, package manager, etc.). This feature will became a main feature and everyone will use that *hope* for ReactOs and also possible for Win32 (from MS). :) -- frik85
"ReactOS Compatibility Database ReactOS has an Compatibility Database where Windows application/driver/hardware compatibility is recorded. Registered users can submit new items, and comment on existing ones. Screen shots are also available for many apps. Users can also vote on their favorite apps." -- a possible description
Design goals User wants to know following things:
- Does my application/driver/hardware work?
- How can I make it work?
- Does it work in the new ReactOS/application/driver/hardware version?
- Where can i download the application (maybe with the ReactOS Package
Manager)?
- list all working and non working application/driver/hardware
Management Issues/Goals:
We need a high 'input data quality', then the administration work will be a minimum. To reach this high data quality, i want to code a simple to use wizard for the 'submit item' page. You can view the sample wizard on the package manager alpha page (see link).
Have some form of a moderation system to let end users know the quality of a given persons entry. Maybe like the appDB from winehq? Where a registered user can ask for a kind of moderator right for one specific item (e.g. application), so he can manage the comments, add new info, etc. -> taking ownership of an item (e.g. application): monitor comments on it, track bugs (close bugs), and make sure quality level is high for application description.
NO redundant entries for the same product! We need moderators who review all new entries. The moderators should be able to read as many comments as possible and help the normal users, report bugs to the bugzilla system, etc.
Reviews (aka user comments) should expire. (expire time 1 year?)
Track hit counts on each item (auto magic way of knowing which apps are most desired) and maybe voting like in appDB (WineHQ) or in C4 (CodeWeaver).
Some ideas i found in old winehq's neewsletters: (maybe useful for our project!)
"Idea: Tie the apps database to the api database. The idea is that we know from the apps database which apps are the most popular. We know from the api database which DLLs/entry points are used by those apps. We can then create a report out of the api database of the list of the DLLs most needed by the top ten apps, and then people writing test scripts (something Alexandre and John Sturtz are working on), have a prioritized todo list. Again, this helps us find useful things for the many volunteers to do." -- winehq newsletter from 18 Oct 2000
Note: maybe a good idea to create such a api database; -> a simalar api status output is currently generated from the svn server (with a small console based application, see build tools). You can view the api status on the svn server. A great chance to import the data to the database and make the idea above possible! The only question, is it usefull for someone? -- frik85
"Idea: Tie the apps database to bugzilla. If users have a problem with an app, it's a bug, and should be in bugzilla. If we can get to a point where we can easily get a report that says 'here are all the bugs that Quicken depends on'. Or, here are the five bugs, the fixing of which will make 50 apps suddenly work. This would be wicked cool." -- winehq newsletter from 18 Oct 2000
Note: the bugzilla will be a subsystem of the RosCMS, so it will be (maybe) possible to implement the idea above. Is something like this usefull for someone? -- frik85
"if we add some 'relay statistics' in Wine code (of course, there will be problems with COM objects where relaying does not work for now) and incorporate these statistics in the database, we could have a list of the most frequently used Windows calls. (feel free to add new ideas for improvements :-) )" -- winehq newsletter from 28 Dec 2000
"He [who take ownership of an item] definitely should have the application installed and, very preferably, he should also be using it regularly (or testing it regularly if it is not yet in the usable state). You are right in pointing out that he cannot test all possible but I contend he does not have to. His role would be to: read the comments entered in the application's comment section. engage into a discussion with the users who post interesting tricks, information, report a sub-version as not working, report problems with a specific Wine/Windows combination extract and summarize the above in his application status report. This section would come first in the application's page and only the application maintainer would be allowed to modify it (whether it's strictly enforced or not is another issue) test the application regularly and update the information on the application's page help users having problems with that application " -- winehq newsletter from 28 Dec 2000
"Jeremy White proposed some scheme to help keeping the database usable: I think the biggest problem with the app database is that we get garbage in, it produces garbage out. I think we should not report or even use any user scores until a trusted app db maintainer has validated that user experience (and possibly users can become trusted reporters). Too many people say 'Hey! The main screen came up! That's a 5! Witness the Slashdot post about MS Office 2k. (anyone actually try to use Office 2K in Wine to author a sizable document?)." -- winehq newsletter from 28 Dec 2000
The information we will gain from the support database
- the progress of ReactOS (for devs and normal user)
- the most wanted applications (when we implement a voting / hit counts
feature)
- a reference for application/driver/hardware that doesn't work without
tweaking, to get them working
- people may be able taking 'ownership' of an application and do regular bug
reports / regression testings).
Several questions, where we need a answer:
"How to 'classify' applications ?: the main point was how an application should be identified (think of Word 5 vs. WinWord 5 cs. Word 7.0, and lots of other quirks (limited versions, demo version, patched versions...) What information should we have about an application ?: this would help in knowing the correct context of execution of such an application (target Windows version, used DLLs, used APIs...)" -- winehq newsletter from 28 Dec 2000
- And about a ReactOS releases ?
- How about scoring ?
- What additional information should one application/driver/hardware have?
We need as much ideas, (feedback after the relaunch/while the testing phase), comments, (and flames) as possible the next weeks. After the website relaunch We need volunteers to take responsibility for updating Apps in the Compatibility Database.
We need to discuss this!
Then after the discussions ... only remains the hours of coding and debugging to put it in place :)
Compatibility Databases from other projects:
http://appdb.winehq.org/ http://www.codeweavers.com/compatibility/ http://www.linuxcompatible.org/compatibility.html http://www.ntcompatible.com/compatibility.html
http://www.microsoft.com/whdc/hcl/default.mspx ttp://www.realtimesoft.com/multimon/search.asp http://hardwaredb.suse.de/index.php?LANG=en_UK http://www.testingstandards.co.uk/compatibility_-_database.htm http://www.yellowtab.com/support/hardware/ http://www.iyonix.com/software/ http://www.ardi.com/compat_search.php?name=ALL&category=ALL&status=A...
A kind of Package Database: http://rpmseek.com/index.html?hl=en
If you know other websites that should be listed here, please write an email to the mailing list!
Best regards, Klemens Friedl <frik85>
PS: if you write a comment, do NOT quote whole passages or do NOT quote the whole text! The reason, emails should be readable ...
-- GMX DSL = Maximale Leistung zum minimalen Preis! 2000 MB nur 2,99, Flatrate ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl _______________________________________________ Ros-dev mailing list Ros-dev@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev
This is too much for many people to both read and answer. I gave me a kik and do it anyways.
Klemens Friedl wrote:
ReactOS 'Support Database' for the new ReactOS Homepage
The 'Support Database' will contain the following 'databases':
- Compatibility Database (application, driver and hardware)
- Package Database (a list of download-able applications/driver; principal
for the ReactOS Package Manager) (* Media Database (like the ReactOS Fansite Media Database; maybe we can implement this later))
I think the first 2 is the minimum we need. I'd rather say for the first step this would also be enough. Application compatibility, Locations of working packages. This can be ONE DB. A Media DB is not needed, just a link collection. Maybe it's just easier to generate this from a db-table. But where's the difference between filling a file or a DB
The 'Support Database' (project codename 'RosDB') will base on the package manager alpha page that i have created april 2005.
ok
Note: the package database will be combined with the compatibility datbase. Both 'databases' will share the same 'application tree'! So it will be easy e.g. you browse the compatibility db, you found a working app and think, "i also want to download this app", then you will be able to click on a link (on a central position) and you will be redirected to the package database. In near future it should be possible (if you run ReactOS or Win32 with installed and runing ReactOS Package Manager), that you can select your favorite apps/driver you want to install (navigation like amazone/ebay/compatibility db) and then click install (a normal link on the package manager page) and your running (maybe as a service) ReactOS Package Manager check/capture every clipboard item and if it is a valid 'package style link' then it will connect to the online database and download all the selected apps/driver and download it from mirror server (from their developers/sourceforge/etc.) and then install all items (without or with minimum of user interaction). In my (frik85) opinion, that would be one of the 'hottest' feature someone can imagine (in connection with a homepage, package manager, etc.). This feature will became a main feature and everyone will use that *hope* for ReactOs and also possible for Win32 (from MS). :) -- frik85
I think that's good, amazing and can support that decision. (Merge both DBs)
"ReactOS Compatibility Database ReactOS has an Compatibility Database where Windows application/driver/hardware compatibility is recorded. Registered users can submit new items, and comment on existing ones. Screen shots are also available for many apps. Users can also vote on their favorite apps." -- a possible description
I've never seen a compatibility DB, hoewve I can imagine this: An app can have several versions. Each version can have several Variants (eg. Shareware, Dongled, free) Each of these tuples can have different requirements in terms of dll and drivers /services And thus make compat. fail or succeed. Compatibility is in my Eyes a multi-step (eg. Not at all, Dies at some action, works but this means work by user, works just fine + errors, perfectly, .... more) Every such tuple shall have a note, and voting+comment info for end-users (n-times) to vote on whether it works or not.
*Tested on What reactos version *if problems occoured, what to do *What do I need *Associate a download like a patchfile? *associate a pic (screenshot )`(nice to have)
Information should be delegated further with some kind of hint. eg. If App v1 works, and App v2 has no information about, The system could show "Is suspected to work since v1 worked" or "No info, but see [App v1] as most simmilar" The same shall happen if App v3 variation x has info while App v3 variation z has no info. That's even more suspectable for it to work, too. So a more sure hint may be shown.
Information about compatibility of several drivers, dlls and services shall be collected, too. With the knowledge of the requirements of an app, we can infer the information of wheter an app is supposed to work or not.
OK, this becomes sofisticated. But a DB should be defined from begin on full, souldn't it?
Management Issues/Goals:
We need a high 'input data quality', then the administration work will be a minimum. To reach this high data quality, i want to code a simple to use wizard for the 'submit item' page. You can view the sample wizard on the package manager alpha page (see link).
Have some form of a moderation system to let end users know the quality of a given persons entry. Maybe like the appDB from winehq? Where a registered user can ask for a kind of moderator right for one specific item (e.g. application), so he can manage the comments, add new info, etc. -> taking ownership of an item (e.g. application): monitor comments on it, track bugs (close bugs), and make sure quality level is high for application description.
I see it as this: Let someone of ours have the apps entered and let people vote about wheter an app works or not. The wiki principle applies. Of couse we can vote, too.
NO redundant entries for the same product! We need moderators who review all new entries. The moderators should be able to read as many comments as possible and help the normal users, report bugs to the bugzilla system, etc.
sure
Reviews (aka user comments) should expire. (expire time 1 year?)
????
Track hit counts on each item (auto magic way of knowing which apps are most desired) and maybe voting like in appDB (WineHQ) or in C4 (CodeWeaver).
nice to have, but at least a good idea
"Idea: Tie the apps database to the api database. The idea is that we know
As i sayd before
"Idea: Tie the apps database to bugzilla. If users have a problem with an app, it's a bug, and should be in bugzilla. If we can get to a point where we can easily get a report that says 'here are all the bugs that Quicken depends on'. Or, here are the five bugs, the fixing of which will make 50 apps suddenly work. This would be wicked cool." -- winehq newsletter from 18 Oct 2000
Note: the bugzilla will be a subsystem of the RosCMS, so it will be (maybe) possible to implement the idea above. Is something like this usefull for someone? -- frik85
I can't imagine this. I'd vote against
Thanks, for your reply!
Robert Köpferl rob@koepferl.de wrote: An: ReactOS Development List ros-dev@reactos.com Betreff: Re: [ros-dev] ReactOS 'Support Database' for the new ReactOS Homepage (ideas, goals, questions) Datum: Fri, 26 Aug 2005 03:03:28 +0200
This is too much for many people to both read and answer. I gave me a kik and do it anyways.
Klemens Friedl wrote:
ReactOS 'Support Database' for the new ReactOS Homepage
The 'Support Database' will contain the following 'databases':
- Compatibility Database (application, driver and hardware)
- Package Database (a list of download-able applications/driver;
principal
for the ReactOS Package Manager) (* Media Database (like the ReactOS Fansite Media Database; maybe we can implement this later))
I think the first 2 is the minimum we need. I'd rather say for the first step this would also be enough. Application compatibility, Locations of working packages. This can be ONE DB. A Media DB is not needed, just a link collection. Maybe it's just easier to generate this from a db-table. But where's the difference between filling a file or a DB
May idea was to combine the compatibility and package database. e.g. when a user found a interesting app that is known for working, he should be able to downlaod and install it with a view clicks.
The 'Support Database' (project codename 'RosDB') will base on the
package
manager alpha page that i have created april 2005.
ok
Note: the package database will be combined with the compatibility
datbase.
Both 'databases' will share the same 'application tree'! So it will be
easy
e.g. you browse the compatibility db, you found a working app and think,
"i
also want to download this app", then you will be able to click on a
link
(on a central position) and you will be redirected to the package
database.
In near future it should be possible (if you run ReactOS or Win32 with installed and runing ReactOS Package Manager), that you can select your favorite apps/driver you want to install (navigation like amazone/ebay/compatibility db) and then click install (a normal link on
the
package manager page) and your running (maybe as a service) ReactOS
Package
Manager check/capture every clipboard item and if it is a valid 'package style link' then it will connect to the online database and download all
the
selected apps/driver and download it from mirror server (from their developers/sourceforge/etc.) and then install all items (without or with minimum of user interaction). In my (frik85) opinion, that would be one
of
the 'hottest' feature someone can imagine (in connection with a
homepage,
package manager, etc.). This feature will became a main feature and everyone will use that
*hope*
for ReactOs and also possible for Win32 (from MS). :) -- frik85
I think that's good, amazing and can support that decision. (Merge both DBs)
see answer above
I've never seen a compatibility DB, hoewve I can imagine this:
I added some useful links to other compatibility db's to the end of the text!
An app can have several versions. Each version can have several Variants (eg. Shareware, Dongled, free) Each of these tuples can have different requirements in terms of dll and drivers /services And thus make compat. fail or succeed. Compatibility is in my Eyes a multi-step (eg. Not at all, Dies at some action, works but this means work by user, works just fine + errors, perfectly, .... more) Every such tuple shall have a note, and voting+comment info for end-users (n-times) to vote on whether it works or not.
*Tested on What reactos version *if problems occoured, what to do *What do I need *Associate a download like a patchfile? *associate a pic (screenshot )`(nice to have)
Information should be delegated further with some kind of hint. eg. If App v1 works, and App v2 has no information about, The system could show "Is suspected to work since v1 worked" or "No info, but see [App v1] as most simmilar" The same shall happen if App v3 variation x has info while App v3 variation z has no info. That's even more suspectable for it to work, too. So a more sure hint may be shown.
Information about compatibility of several drivers, dlls and services shall be collected, too. With the knowledge of the requirements of an app, we can infer the information of wheter an app is supposed to work or not.
OK, this becomes sofisticated. But a DB should be defined from begin on full, souldn't it?
The question is how should it be implemented?
In crossover's c4 they list every app version as a new entry in the app-tree. In winehq's appDB they list one app and when you open the app entry you will see a list of the different (app) versions that has been tested.
I like the winehq's way.
The question is should we step forward and should also list every ReactOS version in its own list?
The reason: wine releases are more often then ReactOS releases. So every ReactOS release has many new features.
From my point of view the ReactOS releases will differ a lot.
Another question: if so, how should this two versions list be implemented?
a possible structure:
* Compatibility: ** Software *** Productivity **** Abiword **** Open Office ***** 1.1.2 ****** ReactOS 0.2.5 (on this page, comments, info, etc.) ****** ReactOS 0.2.6 (on this page, comments, info, etc.) ***** 1.1.3 ****** ReactOS 0.2.5 (on this page, comments, info, etc.) ****** ReactOS 0.2.6 (on this page, comments, info, etc.) ***** 1.1.4 ****** ReactOS 0.2.6 (on this page, comments, info, etc.) ****** ReactOS 0.2.7 (on this page, comments, info, etc.) ***** 2.0 beta ****** ReactOS 0.2.7 (on this page, comments, info, etc.) ****** ReactOS 0.3 SVN (on this page, comments, info, etc.) *** Games ** Hardware
What's your opinion about this structure?
Have some form of a moderation system to let end users know the quality
of a
given persons entry. Maybe like the appDB from winehq? Where a registered user can ask for a
kind
of moderator right for one specific item (e.g. application), so he can manage the comments, add new info, etc. -> taking ownership of an item (e.g. application): monitor comments on
it,
track bugs (close bugs), and make sure quality level is high for
application
description.
I see it as this: Let someone of ours have the apps entered and let people vote about wheter an app works or not. The wiki principle applies. Of couse we can vote, too.
The registered user should be able to write compatbility reports and feed the database with that. Moderators, Tester, Devs and Admins should review the reports and verify the report results (if possible) and set the reports that are "valid"/true as "active" -> then the report data should be visible in the database for everyone and should be signed by the revieweres account name (-> look at c4 db).
Reviews (aka user comments) should expire. (expire time 1 year?)
????
This idea was anncounced the first time on the winehq mailing list.
Many comments will be only a report of the current state, so this should expire.
On 8/23/05, Klemens Friedl klemens_friedl@gmx.net wrote:
Have some form of a moderation system to let end users know the quality of a given persons entry. Maybe like the appDB from winehq? Where a registered user can ask for a kind of moderator right for one specific item (e.g. application), so he can manage the comments, add new info, etc. -> taking ownership of an item (e.g. application): monitor comments on it, track bugs (close bugs), and make sure quality level is high for application description.
Let users submit entries to the database, but have the Testing Team (when I get one together) review, moderate, and approve the entries. We would be in the best position to know about any related bugs.
Track hit counts on each item (auto magic way of knowing which apps are most desired) and maybe voting like in appDB (WineHQ) or in C4 (CodeWeaver).
I like this idea.
WD
-
David Johnson -
Klemens Friedl -
Robert Köpferl -
WaxDragon