The official unofficial Cinelerra repository

The source code of the community Version of Cinelerra is available from a git repository. To get it you need to have git-core installed.

You can clone the repo of the last stable release (2.2) with:

git clone git://git.cinelerra.org/CinelerraCV.git -b rel2.2.0 cinelerra-cv-2.2

Alternatively you can clone the ever growing git repository:

git clone git://git.cinelerra.org/CinelerraCV.git cinelerra-cv

To browse the repo just go to the official CinelerraCV Gitweb page.

Guidelines

The official repository

The official CinelerraCV git repository is managed by core developers.

The master branch stores the live development.
Every official release freezes the development into a dedicated branch.

Changes must be approved by 2 core developers.

Core developers

Core developers are Cinelerra hackers that are happy to accept a small responsibility to help CinelerraCV grow.
Core developers are volunteers that help Cinelerra in their spare time.
Core developers regularly work on CinCV code (when they can) and regularly communicate with the Community (when they can).
Core developers do peer reviewing, discuss about patches by core developers and other contributors.
Core developers keep an eye on the bug tracker.
They also discuss about long term general development choices.
Core developers have access to the official repository.
When a core developer can't be a core developer anymore s/he tells that to the Community before disappearing.

There are some minimum requirements for new developers:

Anyone who wants to become core developer of Cinelerra must have had at least two accepted commits to the official Cinelerra master branch.
Then he/she can send letter of application to mailing list describing what he/she wants to do as a core developer.
Commit access will be discussed and decided by the core developers.

Other contributors

Occasional code contribution is very welcome.

Patch storage

We want the contributed code stored in a stable place, with easy access to be sure that we have a copy of the original patch forever. That's why we ask contributors to upload the patch on the Cinelerra server (git.cinelerra.org, bugs.cinelerra.org.).
Small patches (max 60KB) can be sent to the mailing list as an e-mail attachment.
The Trac powered bug tracker is set to accept attachements as big as 256KB.
Bigger patches can be committed to the "mob" GIT repository.
Frequent contributors can ask for a personal git repository.

Any patch not immediately available or loaded onto a site that needs some quirk for downloading (registration, waiting times, fees...) will be rejected automatically.

Mail notification

Contributions must be notified to the mailing list.
Patches must start a new thread whith subject

[PATCH] Name of the patch

The body of the message must contain the description of the patch and must include the reference (link) to the patch.

Interaction with the community

Contributors are asked to collaborate for the integration.
Contributors must accept that their contribution will be reviewed by core developers, and can thus be rejected, with detailed comments.
Core developers will normally review the contribution within two weeks.
If no reply is given within four weeks, the contributor may send a reminder.

For Cinelerra's sake, contributors are asked to keep up the effort, improve and resubmit the work.
Please note: the mailing list is not a patch dump, but a place for collaborative work.

Proposed changes (patches or git commits)

Every change must be approved by at least 2 core developers before being integrated into the official repository.
Exceptions that can be commited by one developer are obvious bugfixes or fixes to recent commits.

Every change must:

1. address a single feature

Separate, single-feature commits are easier to review and test. They also help building a clear history, making reversions possible.
This should apply at any level. For instance, even the creation of a new theme requires two commits:
1. making a copy of an old theme and rename it
2. applying changes to the theme

2. have a descriptive log

The change must be accompanied by the "what" and "why", with a detailed description directed at developers that are likely at least half-aware of what is going on in the subsystem that is being changed.
The message should explain what the subsystem _should_ do, what it actually does (i.e. the reason of the bug) and how to reproduce the problem. If the bug fix is non-obvious, it should be explained as well. Possible complications of the change, risks, limitations or known bugs must also be included.
Every significant (non trivial) change should be linked to a Trac ticket number and possibly to a milestone.

3. be non-destructive

Features should not be removed or replaced without a very good reason (discussed and approved by core developers).

4. try hard to be compatible

Ideally the new version of CinCV should e able to import a project created in a former version of CinCV. Yet, when important innovations requires it, compatibility can be broken: projects saved from a newer version may not load to previous version.
In such cases, the change will be clearly marked with a tag. The ability to open old projects will be kept by maintaining an older version, keeping it buildable.
Compatibility between CinCV and CinHV is not a priority.

Patches must not introduce new compiler warnings when compiled with modern compilers. (Warnings can be ignored if the cause is outside of current patch).

5. follow the style

The new code should adhere to the coding standard that is used in surrounding code.
It is good tone to copy the coding style that you find rather than to force your own style onto existing code (e.g. white-space style, using tabs, not 8 spaces).

Different parts of Cinelerra have different coding styles. The most common is:

int main()
{
int i;

if(i == 1)
{
i = 2;
}
}
In this example white spaces are made using tabs as follows:
int main()
{
<tab>int i;

<tab>if(i == 1)
<tab>{
<tab><tab>i = 2;
<tab>}
}

FIXME: add an Howto set up emacs, vi, and so on to follow this style

Patches must not have excessive empty lines, commented out parts of code, debug messages.

Notes about new files

The license of a new file must be compatible with GPLv2.

Files that are not created by the author of the patch must have the origin mentioned (at least in the commit log).

Every new graphical element is a new file.
It must have a "by" line (at least a notice with the author's name in the commit log) and a copyright notice.
It must be proved that the artwork is permitted to be used in Cinelerra.

Notes about git commit messages

The git commit message should be properly formatted:

a single summary line (max 76 characters),
a blank line,
the detailed description.
Last modified on Nov 13, 2011