DevGuide.md

@@ -0,0 +1,52 @@
+## Development guide
+
+The programming language of libburnia is ANSI C. Its build system is autotools,
+but the sources do not depend on that. The target operating systems for now
+are Linux with kernels >= 2.4, FreeBSD, NetBSD, Solaris, OpenBSD. Other X/Open
+compliant systems are supported for POSIX i/o but not for MMC/SCSI command
+transactions, which are needed for operating optical drives directly.
+
+Any special dependency to the operating system must be in source
+files separate from the generally portable C code.
+
+Please try to keep the current coding style in each of the source files you
+want to change.
+
+The APIs and ABIs of released library versions are strongly protected towards
+the future. Substantial effort must be made in order to maintain compatibility
+to the previously released version. A break of compatibility and thus
+incrementing of SONAME is only the outmost last resort, if ever. This shall
+ensure that applications can be linked dynamically with all libraries which
+are younger than the versions which where present at compile time.
+
+
+### Patches
+
+Patches should be submitted to mailing lists
+`pkg-libburnia-devel@lists.alioth.debian.org` or `bug-xorriso@gnu.org`.
+When starting to work on something, please announce this in advance,
+explain the problem you want to address and the idea how to solve it,
+if such an idea already exists.
+
+Expect your patch to be discussed and possibly to be modified before being
+applied.
+
+By contributing code, you accept that smaller code pieces go under copyright
+of respective module copyright owners. If your code is substantial enough
+to create own copyright, you will have to release it under LGPL version 2,
+so that we can now derive GPLv2-or-later but are free to switch in future
+to LGPLv2.
+
+
+### Commit policy
+
+A general rule of a thumb is to make more small patches or commits instead
+of one huge commit.
+Please be descriptive in your commit messages.
+
+
+### Releases
+
+Releases are normally performed by Thomas Schmitt.
+Release preparation includes a feature freeze and careful testing.
+