Open Source Development Policies and Procedures for MLT
by Dan Dennedy

Policies
--------

Any contribution to the "core" module must assign copyright to Ushodaya
Enterprises Limited because they need license control over that module.

The framework and libmvsp client libraries are covered under LGPL. melted,
melt, melted-console, and melted-client applications are covered under GPL. Modules
should strive to be LGPL to make them available through the framework as LGPL.

Comments in the framework and libmvsp header files must be C-style, not C++.

Coding Style:
There are not a lot of rules, but we prefer brackets on their own line,
indents using tabs, liberal usage of spaces in statements and expressions, and
no hard line length. The code in src/framework serves as a good example.

Commit messages must be prefaced with the name of the changed files. This makes
the Subversion log more useful as a ChangeLog. For example,
    docs/policies.txt: added policy about commit message

Increment the version number in ./configure, mlt.h, and melt.1 on the first
commit after a release as well as just prior to a new release. This way we can
track if someone is using an unreleased version from the source code repository.

Do not write messages to stdout. stdout is reserved for writing streams that
can be redirected: e.g. raw DV in consumer_libdv. I recommended to use the
mlt_log API. For something quick and dirty, use stderr.


Procedures
----------

Update services.txt when you add or update a service.

Setting Copyright on Appropriated Code:
You do not want to be accused of copying someone's code and changing copyright
or license without permission. The license is straightforward: you must retain
the original author's license unless you receive explicit permission. There are
a few ways to approach the copyright declaration depending upon the
intermingling and changes. If you heavily comingle original and new code or
lightly modifiy the original code, you can retain the original's copyright
including the years, and then add your copyright for the current year. If you
can separate the MLT integration from the core subroutines, then you can put
the core subroutines into a separate file with the original copyright and just
copyright the MLT integration code as your own. However, if you have heavily
modified the original code beyond nearly all recognition, you can copyright it
as your own and attribute the original author as inspiration.

A producer should validate its input and return NULL on failure.

A filter or transition should express the image format it wants before calling
mlt_frame_get_image(). It should expect to receive what it requested as long
as it is yuv422, rgb24, or rgb24a and you are using the imageconvert filter
(typically via the loader producer and its loader.ini file).

Bug Reporting:
First preference is to use the SourceForge tracker:
http://sourceforge.net/tracker/?group_id=96039&atid=613414
Second preference is in the mailing list:
mlt-devel@lists.sourceforge.net