Re: [ros-dev] ReactOS 'Support Database' for the new ReactOS Homepage (ideas, goals, questions)

[Klemens Friedl]

Thanks, for your reply!


> Robert Köpferl <rob at koepferl.de> wrote:
> An: ReactOS Development List <ros-dev at 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. 



-- 
Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner