Contributor Guide
Contributing In General
Our project welcomes external contributions. If you have an itch, please feel free to scratch it.
To contribute code or documentation, please submit a pull request.
A good way to familiarize yourself with the codebase and contribution process is to look for and tackle low-hanging fruit in the issue tracker. Before embarking on a more ambitious contribution, please quickly get in touch with us.
Note: We appreciate your effort, and want to avoid a situation where a contribution requires extensive rework (by you or by us), sits in backlog for a long time, or cannot be accepted at all!
Proposing new features
If you would like to implement a new feature, please raise an issue before sending a pull request so the feature can be discussed. This is to avoid you wasting your valuable time working on a feature that the project developers are not interested in accepting into the code base.
Fixing bugs
If you would like to fix a bug, please raise an issue before sending a pull request so it can be tracked.
Merge approval
The project maintainers use LGTM (Looks Good To Me) in comments on the code review to indicate acceptance. A change requires LGTMs from two of the maintainers of each component affected.
For a list of the maintainers, see the MAINTAINERS.md page.
Legal
Each source file must include a license header for the Apache Software License 2.0. Using the SPDX format is the simplest approach. e.g.
/*
Copyright <holder> All Rights Reserved.
SPDX-License-Identifier: Apache-2.0
*/
We have tried to make it as easy as possible to make contributions. This applies to how we handle the legal aspects of contribution. We use the same approach - the Developer's Certificate of Origin 1.1 (DCO) - that the Linux® Kernel community uses to manage code contributions.
We simply ask that when submitting a patch for review, the developer must include a sign-off statement in the commit message.
Here is an example Signed-off-by line, which indicates that the submitter accepts the DCO:
Signed-off-by: John Doe <john.doe@example.com>
You can include this automatically when you commit a change to your local git repository using the following command:
git commit -s
Communication
Please feel free to connect with us on our ibm-research.slack.com.
Setup
Clone the repo and enter the workspace
git clone https://github.com/foundation-model-stack/multi-nic-cni.git
cd multi-nic-cni-operator
Requirements
- go
- operator-sdk
- utility tools
- environment substitution envsubst (gettext)
- YAML processor yq (yq)
Testing
- Unit test
make test
- Local functional test in your local cluster
Build and deploy locally
- Deploy network
- Check all-to-all connections
- Test your new feature (if proposing new feature)
Coding style guidelines
Follow effective GO.
Please run go fmt
for every packages before submitting PRs.