Want to contribute to Sysbox? Thanks, the Sysbox community welcomes your contributions!
This page contains information about the process to contribute.
- Reporting security issues
- Reporting other issues
- Documentation Changes
- Developer's guide
- We welcome pull requests
- Criteria for accepting changes
- Open-source vs. proprietary functionality
- Write clean code
- Testing is super important
- Please keep the documentation up to date
- Process for creating pull requests
- Sign your work
Strong container security is of upmost concern for Sysbox.
If you are reporting a security issue, please do not create an issue or file a pull request on GitHub. Instead, disclose the issue responsibly by sending an email to [email protected].
Please follow these guidelines when filing issues with Sysbox.
In all cases, first search existing issues, as it's likely the bug has already been reported (and we want to avoid multiple bugs for the same issue).
-
Create a GitHub issue with the label "Bug"
-
Add a label corresponding to the Sysbox release (e.g.
v0.2.0) -
Describe the issue as clearly and completely as possible.
-
Describe how to best reproduce it.
-
Include information about the host's Linux version (e.g.,
lsb_release,uname -a). -
If appropriate, consider generating a core-dump of the Sysbox daemon that is not operating as expected. Refer to this link for the details.
-
Create a GitHub issue with the label "Enhancement"
-
Add a label corresponding to the Sysbox release (e.g.
v0.2.0) -
Describe the need for the proposed enhancement.
-
Provide a high-level description of the enhancement and its benefits.
-
Create a GitHub issue with the label "Documentation"
-
Describe the need for the proposed documentation change.
If you wish to contribute code changes to Sysbox, the developer's guide has all the info to help you setup your environment for building and testing Sysbox.
We appreciate your pull requests, as they help us improve Sysbox.
A pull request can fix or improve any aspect of Sysbox, from a minor documentation typo to an important feature.
For pull requests that fix bugs, add features / functionality, or change documentation in important ways, we ask that you first file an issue (see prior section), such that the pull request can be coupled to that issue.
For minor changes (e.g., a small documentation typo, a small code refactoring, adding a small test, etc.), you can file the pull request without filing an issue for it.
If your pull request is not accepted on the first try, don't be discouraged. The community will do its best to give you constructive feedback so you can improve the pull request.
The Sysbox maintainers are in charge of approving pull requests.
They will do so based on:
-
The need for the change.
-
Whether the change meets the goals of Sysbox project's community.
-
The quality of the change.
-
The testing done (when appropriate).
To ensure synergy between the Sysbox project and companies that wish to build products based on it (such as Nestybox), we use the following criteria when considering adding functionality to Sysbox:
Any features that mainly benefit individual practitioners are made part of the Sysbox open-source project. Any features that mainly address enterprise-level needs are not part of the Sysbox open-source project.
The Sysbox maintainers will make this determination on a feature by feature basis, with total transparency.
This way, the Sysbox open source project satisfies the needs of individual practitioners while giving companies such as Nestybox the chance to monetize on enterprise-level features (which in turn enables Nestybox to continue to sponsor the Sysbox open source project).
Write clean code (keep it simple, make it easy to understand for your fellow contributors).
Sysbox is written in Go. Always run gofmt -s -w file.go
on each changed file before committing your changes. Most editors have plugins
that do this automatically.
All functional changes to Sysbox must pass the Sysbox's regression test suite before the pull request can be accepted.
In addition, changes that fix bugs or add new functionality must be accompanied with a corresponding set of tests.
In Sysbox, tests are divided into two categories:
-
Unit tests: written with Go's "testing" package.
-
Integration tests: written using the bats framework.
In general, having a combination of these is best, with unit tests performing thorough testing (main code paths, corner-cases, etc) and integration tests focusing on interaction of the target functionality with other aspects of Sysbox or the rest of the system.
The developer's guide has the info on how to run Sysbox tests.
Sysbox is a complex piece of software. As such, clear and concise documentation describing its features and functionality is of upmost importance.
Please update the docs whenever:
-
You see a mismatch between the document and existing functionality.
-
You add a new feature.
-
You change or remove an existing feature.
-
You spot typos, missing docs, or unclear/incorrect docs.
And remember: the documentation is as important as the software itself.
-
Fork the Sysbox repo
-
Make changes on your fork in a dedicated branch.
- Name it XXX-something where XXX is the number of the issue (e.g., "202-fix").
-
Test your changes (see above.
-
Commit the changes in your branch
-
Commit messages must start with a capitalized and short summary (max. 70 chars) written in the imperative, followed by an optional, more detailed explanatory text which is separated from the summary by an empty line.
-
For example:
"Add a command line option to configure logging in sysbox-mgr.
Add the "--log-level" option to the sysbox-mgr, to configure logging levels. We initially support the following log-levels ..."
-
Sign-off the commit (see next section).
- Submit the pull request.
-
Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
-
Pull requests must not contain commits from other users or branches.
Code review comments may be added to your pull request. Discuss, then make the suggested modifications and push additional commits to your feature branch. Be sure to post a comment after pushing. The new commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
Before the pull request is merged, make sure that you squash your commits into
logical units of work using git rebase -i and git push -f. After every
commit the test suite should be passing.
Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
Commits that fix or close an issue should include a reference like Closes #XXX or Fixes #XXX.
The sign-off is a simple line at the end of the explanation for the patch, which certifies that you wrote it or otherwise have the right to pass it on as an open-source patch.
The rules are pretty simple: if you can certify the below (from developercertificate.org):
Developer Certificate of Origin
Version 1.1
Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
660 York Street, Suite 102,
San Francisco, CA 94110 USA
Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
then you just add a line to every git commit message:
Signed-off-by: Joe Smith <[email protected]>
using your real name (sorry, no pseudonyms or anonymous contributions.)
You can add the sign off when creating the git commit via git commit -s.