Contributing
Collaboration table of contents
The following is a guide to contributors to encourage a semblance of order.
The top level pothos repository contains a copy of everything. Use the top level repository for normal development workflow.
All directories in the top level repo are actually sourced from separate individual repositories of the same name. The git subtree command is used to push and pull commits to and from the component repositories. Commits to the various subdirectories will be periodically pushed to the respective component repository.
For example, to upload commits to pothos-gui, from the top level repository run:
git subtree push --prefix=pothos-gui [email protected]:pothosware/pothos-gui.git master
Read more about git subtree here:
Most component repositories are separable projects that can be built against the main library. They are maintained separately because its in the roadmap to do away with this top level repository!
There is no issue tracker for the top level. Issues for a component can be found in that component's issue tracker. Use the correct repository to create and comment on issues.
Commits that address a specific issue should mention the issue number in the commit message. Use the #number format to cross reference the issue. That way, after the subtree push is done for the component in question, that commit will be referenced by the issue.
The main Pothos library and most components are available under the Boost Software License (BSL) 1.0. In order to keep it that way, please be conscience of the licensing of external dependencies and code snippets. Copy-left licenses are are only appropriate for component plugin modules, not for the core framework. Permissive licences are preferable to maximize the utility of Pothos for others.
Pothos follows the same copyright model as the Boost project. If you wrote a significant amount of code, anything more than a simple patch or bugfix, append your name, or the name of your organization to the top of the files in question. You wrote that code, you own it, and you agree to license it under the BSL 1.0.
The overall goal is to minimize the number of external dependencies required by the core framework. We would like to keep Pothos as easy to install as possible, even if some components may be a pain to install. Therefore, a new dependency is usually a cause for a new component repository. This avoids burdening an existing repository with new dependencies.
Be creative with the plugin registry: If you think a dependency is required to implement a feature in the core library, you can probably add to the API, however the implementation will call into an optional plugin. The optional plugin contains all of the interfacing with the new dependency. Users that dont have the dependency, dont get the feature.
