git.sesse.net Git - mlt/blob - docs/policies.txt

   1 Open Source Development Policies and Procedures for MLT
   2 by Dan Dennedy
   3
   4 Policies
   5 --------
   6
   7 Any contribution to the "core" module must assign copyright to Ushodaya
   8 Enterprises Limited because they need license control over that module.
   9
  10 The framework and libmvsp client libraries are covered under LGPL. melted,
  11 melt, melted-console, and melted-client applications are covered under GPL. Modules
  12 should strive to be LGPL to make them available through the framework as LGPL.
  13
  14 Comments in the framework and libmvsp header files must be C-style, not C++.
  15
  16 Coding Style:
  17 There are not a lot of rules, but we prefer brackets on their own line,
  18 indents using tabs, liberal usage of spaces in statements and expressions, and
  19 no hard line length. The code in src/framework serves as a good example.
  20
  21 Commit messages must be prefaced with the name of the changed files. This makes
  22 the Subversion log more useful as a ChangeLog. For example,
  23     docs/policies.txt: added policy about commit message
  24
  25 Increment the version number in ./configure, mlt.h, and melt.1 on the first
  26 commit after a release as well as just prior to a new release. This way we can
  27 track if someone is using an unreleased version from the source code repository.
  28
  29 Do not write messages to stdout. stdout is reserved for writing streams that
  30 can be redirected: e.g. raw DV in consumer_libdv. I recommended to use the
  31 mlt_log API. For something quick and dirty, use stderr.
  32
  33
  34 Procedures
  35 ----------
  36
  37 Update services.txt when you add or update a service.
  38
  39 Setting Copyright on Appropriated Code:
  40 You do not want to be accused of copying someone's code and changing copyright
  41 or license without permission. The license is straightforward: you must retain
  42 the original author's license unless you receive explicit permission. There are
  43 a few ways to approach the copyright declaration depending upon the
  44 intermingling and changes. If you heavily comingle original and new code or
  45 lightly modifiy the original code, you can retain the original's copyright
  46 including the years, and then add your copyright for the current year. If you
  47 can separate the MLT integration from the core subroutines, then you can put
  48 the core subroutines into a separate file with the original copyright and just
  49 copyright the MLT integration code as your own. However, if you have heavily
  50 modified the original code beyond nearly all recognition, you can copyright it
  51 as your own and attribute the original author as inspiration.
  52
  53 A producer should validate its input and return NULL on failure.
  54
  55 A filter or transition should express the image format it wants before calling
  56 mlt_frame_get_image(). It should expect to receive what it requested as long
  57 as it is yuv422, rgb24, or rgb24a and you are using the imageconvert filter
  58 (typically via the loader producer and its loader.ini file).
  59
  60 Bug Reporting:
  61 First preference is to use the SourceForge tracker:
  62 http://sourceforge.net/tracker/?group_id=96039&atid=613414
  63 Second preference is in the mailing list:
  64 mlt-devel@lists.sourceforge.net