ColdX Project Charter --------------------- The ColdX Project is a conglomeration of programmers dedicated to advancing the ColdX driver and any relative databases associated with this driver. The ColdX Project directly manages the development of the driver. Development of various databases are of interest and related to the ColdX Project, but the ColdX Project does not assume any responsibility over them. Membership of the ColdX Project is not a tangeable item. Anybody may partake in the ColdX discussions. Anybody may submit source code for the driver, following the ColdX Submission Guidelines. Submission Guidelines --------------------- Anybody may submit changes to the driver, assuming they are appropriate and comply with the following guidelines. 1) Source Code Changes: Source Code Changes are seperated into two categories: a) Non-Impacting Changes: These include simple bug fixes (either reported or not, although it is usually best to report a possible bug, as it may be a known feature) and code optimization. b) Impacting Changes: This category encompases all changes not covered by the first category. Changes which impact the functionality or interface of the driver as well as those which effect the database or database language (ColdC) must first be considered by the ColdX Project team and pass through the development list. 2) Development List: The Development List contains all impacting changes which are currently under scrutiny of the ColdX Project. Changes are defined by a unique name, a quick explanation, and a URL pointing to the file which completely outlines the change (including pros and cons as well as driver and database impacts, if applicable). The URL is only specified if the change is of the calliber to require an indepth explanation (most are). The Development List is divided into five sub categories: a) Suggested Changes This list contains all suggested changes which have not yet been discussed, considered and/or accepted. b) Considered Changes This list contains changes which are currently under scrutiny of the ColdX Project. This is the discussion list for changes to be Accepted. c) Accepted Changes This list contains all changes which have been accepted by the ColdX project. It also contains a reference for who is currently working on the change (if anybody), and when they started. Anybody can claim unclaimed Changes on this list. To do so simply email the ColdX Project manager with your intentions and a brief outline of your implementation ideas (if applicable). The manager will update the list and announce the change in the appropriate medium. d) Suggested and Completed Changes Once an Accepted change has been completed, it is moved to this archive list. e) Suggested but not Accepted Changes This list contains all changes which have been discussed and rejected by the ColdX Project. It also includes what the reasons were for dismissing it, as well as it's possible impacts. 3) Submitting Changes Submitted Changes which do not comply with the following guidelines will not be integrated into the distribution. a) Submit the change to the manager in the form of a patch (unless a previous arrangement has been made with the manager), using the application "diff" with the flags "-rc". The diff must have been executed from the base ColdX tree. This will require a few seperate executions (to include each applicable directory). For instance, patch creation may involve: prompt:/path/ColdX-Version> diff -rc ../ColdX-Old/src src > patch prompt:/path/ColdX-Version> diff -rc ../ColdX-Old/doc doc >> patch prompt:/path/ColdX-Version> diff -rc ../ColdX-Old/bin bin >> patch prompt:/path/ColdX-Version> diff -rc ../ColdX-Old/test test >> patch b) Changes must be clean and commented. This includes no debug functions or lines (including those commented out), and gratuitous or local changes. Comments need not be extensive, although it is best to explain what new functions do--if applicable--at the top of the function definition. c) Every patch must update doc/CHANGES, where the first line of the change specification (index) includes the version, date of release (in brackets, and using the syntax "day(integer)-month(3 characters)-year(integer)", such as [02-Jan-95]), a colon, and a list of contributors to the patch. The body of the change description must be indented at least six spaces, and it is common practice to identify each seperate change with the relative contributor (in the case of multiple contributors).