We love your input! We want to make contributing to this project as easy and transparent as possible, whether it's:
- Reporting a bug
- Discussing the current state of the code
- Submitting a fix
- Proposing new features
- Becoming a maintainer
The functionality being developed under TrenchBoot are cross-cutting capabilities that span multiple open source projects. The role of TrenchBoot is to function as both a development as well as a cross-project integration project. As such it maintains a set of repository clones of upstream project(s) that TrenchBoot conducts development within.
For each upstream repoository within TrenchBoot will have at least one maintainer. The maintainer(s) will have merge permissions and responsible for maintaining adherence to upstream practices. When necessary, they are responsible for maintaining out-of-tree capabilities developed by TrenchBoot.
One of the primary objectives for TrenchBoot is to deliver interoperable launch integrity capabilities to existing open source projects involved with the system boot cycle. Under this objective, all development against an upstream project must comply with upstream coding style and strive to minimize disruption/breakage of upstream capabilities.
There may be a case that a TrenchBoot capability may encounter a slow adoption by an upstream project which results in multiple upstream releases without the capability merged. As such the capability in question must be kept in sync with upstream changes. While this situation is not desired, it is likely to occur and will be the responsibility of the respective TrenchBoot maintainer(s).
While the focus is on delivering capabilities into upstream projects, it is possible that a new or derivative code base may result to fulfill a role in a cross-cutting capability. The maintainer(s) for these code bases will be responsible for establishing coding styles and licensing that ensure compliance with all other TrenchBoot relevant projects.
We use github to host the project, to include tracking issues and feature requests, as well as accept pull requests.
Pull requests are the best way to propose changes to the project (we use Github Flow). We actively welcome your pull requests:
- Fork the repo and create your branch from
master. - If you've added code that should be tested, add tests.
- If you've changed APIs, update the documentation.
- Ensure the test suite passes.
- Make sure your code lints.
- Issue that pull request!
TrenchBoot is a cross-community integration project consisting of project repositories along with upstream project repositories. All contributions to a repository are made under the license that covers all work in that repository.
Report issues, e.g. bugs, feature requests, etc., using Github's issues
Great Issues tend to have:
- A quick summary and/or background
- For bug reports include:
- Steps to reproduce for bugs
- Be specific!
- Give sample code if you can.
- What you expected would happen
- What actually happens
- Notes (possibly including why you think this might be happening, or stuff you tried that didn't work)
- Steps to reproduce for bugs
- For feature requests include:
- An outline of how the feature would work
- Any dependecies the feature would require
- The benefit the feature will provide
Markdown documents should be formatted to 80 columns to the extent possible. Exception to the 80 column is when column limitation breaks markdown rendering.
Contributions targeting upstream project repositories will follow the upstream project's coding style rules.
TrenchBoot is maintained by:
- Daniel P. Smith dpsmith@apertussolutions.com
This document was adapted from the this open-source contribution template