Cheiron

1. General
   1. News
   2. Blogs
   3. Mission
   4. Guidelines
2. Projects
   1. JSC
   2. Seven
   3. Utils
3. Participate
   1. Overview
   2. Repositories
   3. Mailing lists
   4. References
   5. Issue tracking
4. Misc
   1. License
   2. Credits
   3. Legal

Source repositories

The Cheiron Software Configuration Management System is based on Perforce a centralized SCM. Cheiron has been granted a free (as in beer) license on the condition only material that is covered by an official Open Source license enters the repository. In parallel we run Mercurial as the consolidation repositories for the weekly builds that can be utilized by others for development on the Cheiron projects that have no direct commit access on the Perforce repository. Note that Mercurial is experimental at this stage.

License

All material committed to the repositories must be covered by the Apache License, Version 2.0, exceptions can be made for third party libraries that are covered by the following licenses:

• BSD type of licenses, such as the older Apache licenses
• MIT
• CDDL

In order to maintain a unified copyright source base and to be able to defend license violations, we require Contributers to sign a Joint Copyright Assignment and Patent License (pdf) when they submit more than ten lines of code to Cheiron. The transfer is a non-exclusive one, therefore you will keep all rights on your contributions to do with it whatever you like.

We don't like doing this and we are fully aware of the barrier, filling out an assignment with legal implications, but these are a result of Copyright Law, Patent Law and the need for the Cheiron Management Committee to steer Cheiron. The CMC needs the ability to change license conditions if there is a real need for it, or to make the decision to hand over the projects to another organization if there is ever a need for.

Committers should update the copyright notice in the Cheiron Licenses to include the current year when revising a source file. If you modify in 2001 a source file of the year 2000 you have to change the copyright notice in the license to site "2000-2001". If you would have changed the file in 2002 it should site "2000, 2002".

The committers are responsible for enforcing the license and copyright guidelines listed above, a list with all developers/companies that have signed the copyright transfer form can be found here.

Status file

Each of the projects should have a status file which is used to keep track of the agenda and plans for work within that branch. The status file includes information about release plans, a list of proposed changes that are under discussion, brief notes about items that individual developers are working on or want discussion about, and anything else that may be useful to help the group track progress.

Note: 'status file' should be seen as a metaphor for a collection of documents serving this purpose instead of a single file called, especially with regard to all tangible pieces of work the issue tracking system will take care of a lot of status related information and allows for generating project management information. If the information is not stored in the issue tracking system it must be placed under version control.

Branching

Because of Perforce we make extensive use of branches for releases and "revolutions". A branch is considered "evolutionary" by lazy consensus. Upon any dispute (binding veto), work must proceed in a skunk branch with "revolutionary" status, the branch name must be according to the branch naming conventions.

Once a release plan for the main branch has been approved, and the proposed release is ready for extensive testing, a version branch will be created and when ready for public release a release branch. A detailed explanation about the branching policies and tactics can be found in the Cheiron CSM guidelines. In case of releases we expect all work in the version and release branch to be merged completely back into the main branch as soon as a release cycle completes.

Changes

Simple patches to fix bugs can be committed then reviewed. With a commit-then-review process, the committer is trusted to have a high degree of confidence in the change.

Doubtful changes, new features, and large scale overhauls need to be discussed before committing them into the repository. Any change that affects the semantics of an existing API function, configuration data formats, or other major areas must receive consensus approval before being committed.

Related changes should be committed as a group, or very closely together. Half complete projects should never be committed to the main branch of a development repository. All code changes must be successfully compiled on the developer's platform before being committed.

The current code line for a project should always build[1] and pass most tests. However, it is sometimes impossible for a developer on one platform to avoid breaking some other platform when a change is committed. If it is anticipated that a given change will break the build on some other platform, the committer must indicate that in the change description.

A committed change must be reversed if it is vetoed by one of the voting members and the veto conditions cannot be immediately satisfied by the equivalent of a "bug fix" commit. The veto must be rescinded before the change can be included in any public release.

[1] sometime a change involves that much development work one can't guarantee a code line in the repository that will always build, in such circumstances one should opt for a skunk branch. A skunk branch is also required to coordinate work between various committers working on the same issue.

Patches

When a specific change to a product is proposed for discussion or voting on the appropriate development mailing list, it should be presented in the form of input to the patch command. When sent to the mailing list, the message should contain a Subject beginning with [PATCH] and a distinctive one-line summary corresponding to the action item for that patch.