Changes between Version 4 and Version 5 of Developer/Database

Mar 8, 2016, 2:07:29 AM (5 years ago)
Amar Takhar

More details.


  • Developer/Database

    v4 v5  
    77The RTEMS database is a central repository that holds all central project data.  With this we will be able to have a fully cross-referenced repository of information that goes backwards to the creation of RTEMS to the present.  It can also hold data set in the future for releases that have not happened.
    9 There are a central set of 'key' data points that must be filled in on an ongoing process.  They are:
     9== Why ==
     11Why do we want a database?  The single biggest reason is V&V.  We cannot do that by using a wiki there is no way to validate the data as being correct since we do not know how it relates to other data points.  For example, these are questions we cannot answer or cannot easily answer:
     13  * How many Apps does RTEMS know?
     14    * What BSPs do they use?
     15    * What boards?
     16    * What CPUs?
     17  * How many CPU Families does RTEMS support.
     18  * I have CPU X does '''any''' version of RTEMS support it?
     19  * How reliable is RTEMS Networking?  What version has the most stable IPv4 implementation
     20    * This will be gleaned from automatic testing we don't have to enter this!
     21  * What are all the changes to the RTEMS Kernel in reverse chronological order that resulted in the reliability of RTEMS going down
     22    * What compiler was used?  What version?
     23  * I want to run an ARM BSP with CPU X using GCC Y with Simulator K.
     24    * Can I do this?  Yes?
     25    * What version of GCC is the most reliable.  What version of RTEMS?
     26    * What BSP is the most reliable in ARM?
     27    * What Boards do we test against for ARM?
     29The above are examples of questions that are difficult to answer or cannot be answered at all.  By recording Build information from test runs and linking this to all other RTEMS data we can provide users with extremely in depth reports about a version, change, tool, platform or any other data point in the Description section below.
     33== Description ==
     35This is high level overview.
    1137  * '''Architecture'''
    78104The only way to edit the database is via the default [ Django] admin site.  It gets the job done all the focus has been put on the frontend.  Eventually a nice, AJAX page will be created to ease adding !ChangeLog entries as these will be the most edited item.
    80 The admin site is self explanatory and data input is enforced with validation it is very difficult to input incorrect data.
     106The admin site is self explanatory and data input is enforced with validation it is very difficult to input incorrect data.
     108=== Fixing an Issue ===
     110Since the database is relational there is only one point you will need to edit for any single error.  The database has been decided to only store one data point.
     112When information from the database is used it will, in most cases be labeled.  For instance if the description for a `CPU` is wrong you should look in the `CPU` table.  The admin interface also offers a search feature that can be used to locate data within each table.
     114== Retention ==
     116The RTEMS project has decided to retain all data collected permanently.  We will never delete any recorded data this includes but is not limited to:
     118  * The RDB.
     119  * Build results.
     120  * Binaries resulting from a build.
     121    * RTEMS libraries
     122    * Tools (all types)
     123  * All source files and packages.
     124  * Platform images.
     126=== Validation & Verification ===
     128The purpose of retaining all data is to allow anyone to independently validate our test results using the exact same setup we used ourselves.  By simulating our primary build platforms we will be able to ensure our environments are not different from what a user will use.  We will be providing these images for download with tools pre-installed on a rolling basis.  These images are not designed for use as a user but are strictly the result of our test building.  This will make it possible to repeat results 10, 20 even 50 years down the road where it would be difficult if not impossible to collect.
     130All commands used to build each tool or software package will be recorded along with their build output and recorded forever.