Changes between Version 2 and Version 3 of Developer/Database


Ignore:
Timestamp:
Mar 8, 2016, 1:18:32 AM (4 years ago)
Author:
Amar Takhar
Comment:

Progress save.

Legend:

Unmodified
Added
Removed
Modified
  • Developer/Database

    v2 v3  
    1616  * '''!ChangeLog'''
    1717    * Rolling list of changes that users will care about.
     18  * '''Component'''
     19    * Major components of RTEMS.  API, Block Devices, Clients, Kernel, Networking, Servers, Shell...
    1820  * '''CPU'''
    1921    * Individual CPUs supported
     
    2830  * '''Orginisation'''
    2931    * An orginisation is any org that interacts with RTEMS in some way both commercial, other projects and nonprofit.  This is keyed to many other data points within the RDB.
     32  * '''Project'''
     33    * Toplevel key: What project all the resulting data in the DB relates to.  This lets us clone all of this work for any projects under the RTEMS umbrella.
     34  * '''Release'''
     35    * All release versions, maturity and descriptions for RTEMS.
    3036  * '''Tool'''
    3137    * Tools can be Simulators, Compilers, Build tools, Doc tools...
     
    4854      * Space, Medical, Aviation...
    4955
     56== Uses and Explanations ==
     57
     58The RDB is used everywhere:
     59
     60  * Website
     61  * Test suite
     62  * Documentation
     63  * Releases
     64  * !BuildBot
     65
     66The purpose of having a database such as this is to avoid replicating data and ensure perfect resolution of our main data points.  Historically RTEMS has had issues in keeping data up-to-date and accurate.  This type of database removes all possibility of data being outdated as it enforces changing the data before the result can be seen.
     67
     68For example, if we deprecate a release this can be set in the `Release` table which will automatically mark the release as deprecated in all other areas of the database.  The same goes for future releases.  If we set the date in the future it will fall under 'upcoming' releases until we edit the DB to set the version as released.  This will make it front-and-center for the website, testing and documentation.
     69
     70== API ==
     71
     72All RDB data will be available via a JSON REST API that is self-documenting.  This will allow anyone who wishes to use our results and information for their own uses.  API keys will not be enforced however monitoring will be done to avoid abuse
     73
     74All internal tools will use this API to allow for unhooking software from our internal build farm.  This will allow everything to run anywhere it wants without making changes.  If someone wishes to run their own clone of our software and point it to a new API data host they can do so without any input from us.