Thanks for your help improving the project!
If you have a question about Linkerd2 or have encountered problems using it, start by asking a question in the forums or join us in the #linkerd2 Slack channel.
To contribute to this project, you must agree to the Developer Certificate of Origin (DCO) for each commit you make. The DCO is a simple statement that you, as a contributor, have the legal right to make the contribution.
See the DCO file for the full text of what you must agree to.
One way to signify that you agree to the DCO for a commit is to add a line to the git commit message:
Signed-off-by: Jane Smith <jane.smith@example.com>
In most cases, you can add this signoff to your commit automatically with the
-s
flag to git commit
. You must use your real name and a reachable email
address (sorry, no pseudonyms or anonymous contributions).
If you've already made the commits and don't want to engage in git shenanigans to retroactively apply the signoff as above, there is another option: leave a comment on the PR with the following statement: "I agree to the DCO for all the commits in this PR."
Note that this option also requires that your commits are made under your real name and a reachable email address.
If you use this approach, the DCO bot will still complain, but maintainers will override the DCO bot at merge time.
Changes that are trivial (e.g. spelling corrections, adding to ADOPTERS.md, one-word changes) do not require a DCO signoff. Maintainers should feel free to override the DCO bot for these changes.
Do you have an improvement?
main
branch.
We prefer squash or rebase commits so that all changes from a branch are committed to main as a single commit. All pull requests are squashed when merged, but rebasing prior to merge gives you better control over the commit message.
Finalized commit messages should be in the following format:
Subject
Problem
Solution
Validation
Fixes #[GitHub issue ID]
bad: server disconnects should cause dst client disconnects.
good: Propagate disconnects from source to destination
bad: support tls servers
good: Introduce support for server-side TLS (#347)
Explain the context and why you're making that change. What is the problem you're trying to solve? In some cases there is not a problem and this can be thought of as being the motivation for your change.
Describe the modifications you've made.
If this PR changes a behavior, it is helpful to describe the difference between the old behavior and the new behavior. Provide before and after screenshots, example CLI output, or changed YAML where applicable.
Describe any implementation changes which are particularly complex or unintuitive.
List any follow-up work that will need to be done in a future PR and link to any relevant GitHub issues.
Describe the testing you've done to validate your change. Give instructions for reviewers to replicate your tests. Performance-related changes should include before- and after- benchmark results.
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。