Changes between Version 3 and Version 4 of DevelopersDocs


Ignore:
Timestamp:
Aug 9, 2018, 9:51:36 PM (8 months ago)
Author:
chris
Comment:

developer docs

Legend:

Unmodified
Added
Removed
Modified
  • DevelopersDocs

    v3 v4  
    22
    33[[TracNav]]
     4
     5We encourage contributions, especially completed ones (pull requests and patches). However please be aware of some restrictions:
     6
     7* This is backup software, it needs to be simple and reliable.
     8* Almost all of the code is in C++ for performance.
     9* The code is portable (cross-platform) and must remain so.
     10* We have limited capacity to review contributions or respond to emails, so it may take a while.
     11* We prefer not to add complexity where possible, especially if it can be done in a separate process via an interface.
     12* All contributions must be dual-licensed BSD and GPL (can be used under either license).
     13* Please follow the CodingStandards.
     14* Please use Github pull requests where possible.
     15
     16== Simplicity and Reliability ==
     17
     18As this is backup software, our top priority is not to break it, especially silently. If you are developing a new feature, please think about how you can minimise the impact on the rest of the codebase. For example:
     19
     20* Bugs should have tests that demonstrate the problem, which the patch fixes.
     21* Significant new features should have extensive tests. For example, the S3 storage feature includes a near-complete S3 simulator, and most tests are specialised to run on it as well as the old storage backend.
     22* Please add new configuration options sparingly, and especially do not make them required (as that would break existing installations).
     23* Ports to and support for new platforms are especially welcome, as they exercise odd corner cases, but [wiki:BuildAutomation automated testing] is essential. This is why we do not officially support ARM or Solaris platforms at this time.
     24* Instead of adding a new file filtering mechanism (for example), a way to do this in an external process would be far more general and useful.
     25
     26== Language ==
     27
     28Box Backup is designed to be cross-platform, and to run on less powerful systems (for example, NAS devices with embedded Linux), by not hogging resources and having minimal dependencies.
     29
     30* Box Backup is written in C++, so your libraries must be too (or C if the API is simple and doesn't benefit massively from C++, e.g. PCRE, OpenSSL, QDBM).
     31* External libraries are often very well-tested, but should be optional. If necessary, your new feature should automatically be compiled out if the necessary libraries are not present.
     32* This is a cross-platform application. Support for Linux, Mac OS X and Windows is mandatory. Therefore your libraries need to be available on all three.
     33* Libraries may need to be bundled, but it must be possible to unbundle them (some distros require this).
     34* The libraries must have compatible licenses, which basically means BSD 2-clause or MIT licensed, not GPL.
     35* Instead of adding hooks for a new GUI or web UI (for example), if you added language bindings (for example [https://wiki.python.org/moin/SIP SIP] or [http://www.swig.org/ SWIG]) that would have a much bigger and longer-lasting impact.
     36
     37== Portability ==
     38
     39Box Backup was originally developed for UNIX. Windows compatibility was added later, mainly through an emulation layer (lib/win32/emu.cpp/h) which provides POSIX and UNIX-like functions, such as an open() replacement which supports non-ASCII characters in filenames, fstat() and lstat(), opendir(), syslog(), strtoui64().
     40
     41In most cases you can code for UNIX, but be aware when using functions that are not available on Windows, or are replaced by the emulation layer. Where possible use existing C++ classes such as FileStream to access files (which supports locking) and use O_BINARY when opening binary files.
     42
     43We have adopted QDBM databases as they compile easily on Windows, while BDB and TDB do not.
     44
     45== Code reviews ==
     46
     47Code reviews are mandatory before merging. Sometimes we will take your contribution and merge it ourselves, if no changes are required, or only trivial ones.
     48
     49Tests are also mandatory.
     50
     51We have one active developer who works full-time and has a family, so please don't be surprised if it takes days or weeks to review your contribution. After that, please send a reminder!
     52
     53Please use Github Pull Requests where possible. They reduce the time required by us to review and process submissions. The test suite is automatically run on all pull requests, so you'll get quick feedback if something is broken. If it is, please fix it without waiting for us to ask you. Your pull request cannot and will not be merged until the tests pass, at the very least. Don't be surprised if you have to download VirtualBox and install FreeBSD in a virtual machine to debug and fix a failing test.
     54
     55== License ==
     56
     57Box Backup has an unusual [https://github.com/boxbackup/boxbackup/blob/master/LICENSE.txt licensing situation], where part of the code is dual-licensed (BSD and GPL) and part is only GPL. This stems from a time when we were worried about someone taking our code and turning it into a commercial product without giving anything back to the community. This fear has largely passed, so the project may be relicensed in future under the BSD 2-clause license. To support this, all contributions must be licensed under BOTH the BSD 2-clause AND the GPL license, so that they may be used under either.
     58
     59All contributors are required to confirm that they agree to this license for all submissions, in their first pull request or patch submission.
     60
     61== Specific Areas ==
    462
    563Not much here yet: