26 Aug
2005
26 Aug
'05
1:03 a.m.
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