You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
53 lines
2.4 KiB
53 lines
2.4 KiB
15 years ago
|
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 valerie client libraries are covered under LGPL. Miracle,
|
||
|
|
inigo, albino, and humperdink 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 valerie 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 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.
|
||
|
|
|
||
|
|
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.
|
||
|
|
|
||
|
|
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
|