github.com/wangchanggan/helm@v0.0.0-20211020154240-11b1b7d5406d/CONTRIBUTING.md (about) 1 # Contributing Guidelines 2 3 The Helm project accepts contributions via GitHub pull requests. This document outlines the process to help get your contribution accepted. 4 5 ## Reporting a Security Issue 6 7 Most of the time, when you find a bug in Helm, it should be reported 8 using [GitHub issues](https://github.com/helm/helm/issues). However, if 9 you are reporting a _security vulnerability_, please email a report to 10 [cncf-kubernetes-helm-security@lists.cncf.io](mailto:cncf-kubernetes-helm-security@lists.cncf.io). This will give 11 us a chance to try to fix the issue before it is exploited in the wild. 12 13 ## Sign Your Work 14 15 The sign-off is a simple line at the end of the explanation for a commit. All 16 commits needs to be signed. Your signature certifies that you wrote the patch or 17 otherwise have the right to contribute the material. The rules are pretty simple, 18 if you can certify the below (from [developercertificate.org](https://developercertificate.org/)): 19 20 ``` 21 Developer Certificate of Origin 22 Version 1.1 23 24 Copyright (C) 2004, 2006 The Linux Foundation and its contributors. 25 1 Letterman Drive 26 Suite D4700 27 San Francisco, CA, 94129 28 29 Everyone is permitted to copy and distribute verbatim copies of this 30 license document, but changing it is not allowed. 31 32 Developer's Certificate of Origin 1.1 33 34 By making a contribution to this project, I certify that: 35 36 (a) The contribution was created in whole or in part by me and I 37 have the right to submit it under the open source license 38 indicated in the file; or 39 40 (b) The contribution is based upon previous work that, to the best 41 of my knowledge, is covered under an appropriate open source 42 license and I have the right under that license to submit that 43 work with modifications, whether created in whole or in part 44 by me, under the same open source license (unless I am 45 permitted to submit under a different license), as indicated 46 in the file; or 47 48 (c) The contribution was provided directly to me by some other 49 person who certified (a), (b) or (c) and I have not modified 50 it. 51 52 (d) I understand and agree that this project and the contribution 53 are public and that a record of the contribution (including all 54 personal information I submit with it, including my sign-off) is 55 maintained indefinitely and may be redistributed consistent with 56 this project or the open source license(s) involved. 57 ``` 58 59 Then you just add a line to every git commit message: 60 61 Signed-off-by: Joe Smith <joe.smith@example.com> 62 63 Use your real name (sorry, no pseudonyms or anonymous contributions.) 64 65 If you set your `user.name` and `user.email` git configs, you can sign your 66 commit automatically with `git commit -s`. 67 68 Note: If your git config information is set properly then viewing the 69 `git log` information for your commit will look something like this: 70 71 ``` 72 Author: Joe Smith <joe.smith@example.com> 73 Date: Thu Feb 2 11:41:15 2018 -0800 74 75 Update README 76 77 Signed-off-by: Joe Smith <joe.smith@example.com> 78 ``` 79 80 Notice the `Author` and `Signed-off-by` lines match. If they don't 81 your PR will be rejected by the automated DCO check. 82 83 ## Support Channels 84 85 Whether you are a user or contributor, official support channels include: 86 87 - [Issues](https://github.com/helm/helm/issues) 88 - Slack: 89 - User: [#helm-users](https://kubernetes.slack.com/messages/C0NH30761/details/) 90 - Contributor: [#helm-dev](https://kubernetes.slack.com/messages/C51E88VDG/) 91 92 Before opening a new issue or submitting a new pull request, it's helpful to search the project - it's likely that another user has already reported the issue you're facing, or it's a known issue that we're already aware of. It is also worth asking on the Slack channels. 93 94 ## Milestones 95 96 We use milestones to track progress of releases. There are also 2 special milestones 97 used for helping us keep work organized: `Upcoming - Minor` and `Upcoming - Major` 98 99 `Upcoming - Minor` is used for keeping track of issues that aren't assigned to a specific 100 release but could easily be addressed in a minor release. `Upcoming - Major` keeps track 101 of issues that will need to be addressed in a major release. For example, if the current 102 version is `2.2.0` an issue/PR could fall in to one of 4 different active milestones: 103 `2.2.1`, `2.3.0`, `Upcoming - Minor`, or `Upcoming - Major`. If an issue pertains to a 104 specific upcoming bug or minor release, it would go into `2.2.1` or `2.3.0`. If the issue/PR 105 does not have a specific milestone yet, but it is likely that it will land in a `2.X` release, 106 it should go into `Upcoming - Minor`. If the issue/PR is a large functionality add or change 107 and/or it breaks compatibility, then it should be added to the `Upcoming - Major` milestone. 108 An issue that we are not sure we will be doing will not be added to any milestone. 109 110 A milestone (and hence release) is considered done when all outstanding issues/PRs have been closed or moved to another milestone. 111 112 ## Semantic Versioning 113 114 Helm maintains a strong commitment to backward compatibility. All of our changes to protocols and formats are backward compatible from Helm 2.0 until Helm 3.0. No features, flags, or commands are removed or substantially modified (other than bug fixes). 115 116 We also try very hard to not change publicly accessible Go library definitions inside of the `pkg/` directory of our source code. 117 118 For a quick summary of our backward compatibility guidelines for releases between 2.0 and 3.0: 119 120 - Protobuf and gRPC changes MUST be backward compatible. 121 - Command line commands, flags, and arguments MUST be backward compatible 122 - File formats (such as Chart.yaml, repositories.yaml, and requirements.yaml) MUST be backward compatible 123 - Any chart that worked on a previous version of Helm MUST work on a new version of Helm (barring the cases where (a) Kubernetes itself changed, and (b) the chart worked because it exploited a bug) 124 - Chart repository functionality MUST be backward compatible 125 - Go libraries inside of `pkg/` SHOULD remain backward compatible (though code inside of `cmd/` may be changed from release to release without notice). 126 127 ## Issues 128 129 Issues are used as the primary method for tracking anything to do with the Helm project. 130 131 ### Issue Types 132 133 There are 4 types of issues (each with their own corresponding [label](#labels)): 134 - Question: These are support or functionality inquiries that we want to have a record of for 135 future reference. Generally these are questions that are too complex or large to store in the 136 Slack channel or have particular interest to the community as a whole. Depending on the discussion, 137 these can turn into "Feature" or "Bug" issues. 138 - Proposal: Used for items (like this one) that propose a new ideas or functionality that require 139 a larger community discussion. This allows for feedback from others in the community before a 140 feature is actually developed. This is not needed for small additions. Final word on whether or 141 not a feature needs a proposal is up to the core maintainers. All issues that are proposals should 142 both have a label and an issue title of "Proposal: [the rest of the title]." A proposal can become 143 a "Feature" and does not require a milestone. 144 - Features: These track specific feature requests and ideas until they are complete. They can evolve 145 from a "Proposal" or can be submitted individually depending on the size. 146 - Bugs: These track bugs with the code or problems with the documentation (i.e. missing or incomplete) 147 148 ### Issue Lifecycle 149 150 The issue lifecycle is mainly driven by the core maintainers, but is good information for those 151 contributing to Helm. All issue types follow the same general lifecycle. Differences are noted below. 152 1. Issue creation 153 2. Triage 154 - The maintainer in charge of triaging will apply the proper labels for the issue. This 155 includes labels for priority, type, and metadata (such as "starter"). The only issue 156 priority we will be tracking is whether or not the issue is "critical." If additional 157 levels are needed in the future, we will add them. 158 - (If needed) Clean up the title to succinctly and clearly state the issue. Also ensure 159 that proposals are prefaced with "Proposal". 160 - Add the issue to the correct milestone. If any questions come up, don't worry about 161 adding the issue to a milestone until the questions are answered. 162 - We attempt to do this process at least once per work day. 163 3. Discussion 164 - "Feature" and "Bug" issues should be connected to the PR that resolves it. 165 - Whoever is working on a "Feature" or "Bug" issue (whether a maintainer or someone from 166 the community), should either assign the issue to them self or make a comment in the issue 167 saying that they are taking it. 168 - "Proposal" and "Question" issues should stay open until resolved or if they have not been 169 active for more than 30 days. This will help keep the issue queue to a manageable size and 170 reduce noise. Should the issue need to stay open, the `keep open` label can be added. 171 4. Issue closure 172 173 ## How to Contribute a Patch 174 175 1. **Fork** the repo [helm](https://github.com/helm/helm) 176 177 Go to https://github.com/helm/helm then hit the `Fork` button to fork your own copy of repository **helm** to your github account. 178 179 2. **Clone** the forked repo to your local working directory. 180 ```sh 181 $ git clone https://github.com/$your_github_account/helm.git 182 ``` 183 3. Add an `upstream` remote to keep your fork in sync with the main repo. 184 ```sh 185 $ cd helm 186 $ git remote add upstream https://github.com/helm/helm.git 187 $ git remote -v 188 189 origin https://github.com/$your_github_account/helm.git (fetch) 190 origin https://github.com/$your_github_account/helm.git (push) 191 upstream https://github.com/helm/helm.git (fetch) 192 upstream https://github.com/helm/helm.git (push) 193 ``` 194 4. Sync your local `master` branch. 195 ```sh 196 $ git pull upstream master 197 ``` 198 5. Create a branch to add a new feature or fix issues. 199 ```sh 200 $ git checkout -b new-feature 201 ``` 202 6. Make any change on the branch `new-feature` then build and test your codes. 203 7. Include in what will be committed. 204 ```sh 205 $ git add <file> 206 ``` 207 8. Use sign-off when making each of your commits (see [above](#sign-your-work)). 208 If you forgot to sign some commits that are part of the contribution, you can ask [git to rewrite your commit history](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History). 209 ```sh 210 $ git commit --signoff 211 ``` 212 9. Submit a pull request. 213 214 Coding conventions and standards are explained in the official developer docs: 215 [Developers Guide](docs/developers.md) 216 217 The next section contains more information on the workflow followed for Pull Requests. 218 219 ## Pull Requests 220 221 Like any good open source project, we use Pull Requests (PRs) to track code changes. 222 223 ### PR Lifecycle 224 225 1. PR creation 226 - PRs are usually created to fix or else be a subset of other PRs that fix a particular issue. 227 - We more than welcome PRs that are currently in progress. They are a great way to keep track of 228 important work that is in-flight, but useful for others to see. If a PR is a work in progress, 229 it **must** be prefaced with "WIP: [title]". Once the PR is ready for review, remove "WIP" from 230 the title. 231 - It is preferred, but not required, to have a PR tied to a specific issue. There can be 232 circumstances where if it is a quick fix then an issue might be overkill. The details provided 233 in the PR description would suffice in this case. 234 2. Triage 235 - The maintainer in charge of triaging will apply the proper labels for the issue. This should 236 include at least a size label, `bug` or `feature`, and `awaiting review` once all labels are applied. 237 See the [Labels section](#labels) for full details on the definitions of labels. 238 - Add the PR to the correct milestone. This should be the same as the issue the PR closes. 239 3. Assigning reviews 240 - Once a review has the `awaiting review` label, maintainers will review them as schedule permits. 241 The maintainer who takes the issue should self-request a review. 242 - Any PR with the `size/large` label requires 2 review approvals from maintainers before it can be 243 merged. Those with `size/medium` or `size/small` are per the judgement of the maintainers. 244 4. Reviewing/Discussion 245 - Once a maintainer begins reviewing a PR, they will remove the `awaiting review` label and add 246 the `in progress` label so the person submitting knows that it is being worked on. This is 247 especially helpful when the review may take awhile. 248 - All reviews will be completed using Github review tool. 249 - A "Comment" review should be used when there are questions about the code that should be 250 answered, but that don't involve code changes. This type of review does not count as approval. 251 - A "Changes Requested" review indicates that changes to the code need to be made before they will be 252 merged. 253 - Reviewers (maintainers) should update labels as needed (such as `needs rebase`). 254 - Reviews are also welcome from others in the community, especially those who have encountered a bug or 255 have requested a feature. In the code review, a message can be added, as well as `LGTM` if the PR is 256 good to merge. It’s also possible to add comments to specific lines in a file, for giving context 257 to the comment. 258 5. PR owner should try to be responsive to comments by answering questions or changing code. If the 259 owner is unsure of any comment, reach out to the person who added the comment in 260 [#helm-dev](https://kubernetes.slack.com/messages/C51E88VDG/). Once all comments have been addressed, 261 the PR is ready to be merged. 262 6. Merge or close 263 - PRs should stay open until merged or if they have not been active for more than 30 days. 264 This will help keep the PR queue to a manageable size and reduce noise. Should the PR need 265 to stay open (like in the case of a WIP), the `keep open` label can be added. 266 - Before merging a PR, refer to the topic on [Size Labels](#size-labels) below to determine if 267 the PR requires more than one LGTM to merge. 268 - If the owner of the PR is listed in `OWNERS`, that user **must** merge their own PRs or explicitly 269 request another OWNER do that for them. 270 - If the owner of a PR is _not_ listed in `OWNERS`, any maintainer may merge the PR once it is approved. 271 272 #### Documentation PRs 273 274 Documentation PRs will follow the same lifecycle as other PRs. They will also be labeled with the 275 `docs` label. For documentation, special attention will be paid to spelling, grammar, and clarity 276 (whereas those things don't matter *as* much for comments in code). 277 278 ## The Triager 279 280 Each week, one of the core maintainers will serve as the designated "triager" starting after the 281 public stand-up meetings on Thursday. This person will be in charge triaging new PRs and issues 282 throughout the work week. 283 284 ## Labels 285 286 The following tables define all label types used for Helm. It is split up by category. 287 288 ### Common 289 290 | Label | Description | 291 | ----- | ----------- | 292 | `bug` | Marks an issue as a bug or a PR as a bugfix | 293 | `critical` | Marks an issue or PR as critical. This means that addressing the PR or issue is top priority and will be handled first by maintainers | 294 | `docs` | Indicates the issue or PR is a documentation change | 295 | `duplicate` | Indicates that the issue or PR is a duplicate of another | 296 | `feature` | Marks the issue as a feature request or a PR as a feature implementation | 297 | `keep open` | Denotes that the issue or PR should be kept open past 30 days of inactivity | 298 | `refactor` | Indicates that the issue is a code refactor and is not fixing a bug or adding additional functionality | 299 300 ### Issue Specific 301 302 | Label | Description | 303 | ----- | ----------- | 304 | `help wanted` | This issue is one the core maintainers cannot get to right now and would appreciate help with | 305 | `proposal` | This issue is a proposal | 306 | `question/support` | This issue is a support request or question | 307 | `good first issue` | This issue is a good for someone new to contributing to Helm | 308 | `wont fix` | The issue has been discussed and will not be implemented (or accepted in the case of a proposal) | 309 310 ### PR Specific 311 312 | Label | Description | 313 | ----- | ----------- | 314 | `awaiting review` | The PR has been triaged and is ready for someone to review | 315 | `breaking` | The PR has breaking changes (such as API changes) | 316 | `in progress` | Indicates that a maintainer is looking at the PR, even if no review has been posted yet | 317 | `needs pick` | Indicates that the PR needs to be picked into a feature branch (generally bugfix branches). Once it has been, the `picked` label should be applied and this one removed | 318 | `needs rebase` | A helper label used to indicate that the PR needs to be rebased before it can be merged. Used for easy filtering | 319 | `picked` | This PR has been picked into a feature branch | 320 321 #### Size labels 322 323 Size labels are used to indicate how "dangerous" a PR is. The guidelines below are used to assign the 324 labels, but ultimately this can be changed by the maintainers. For example, even if a PR only makes 325 30 lines of changes in 1 file, but it changes key functionality, it will likely be labeled as `size/L` 326 because it requires sign off from multiple people. Conversely, a PR that adds a small feature, but requires 327 another 150 lines of tests to cover all cases, could be labeled as `size/S` even though the number 328 lines is greater than defined below. 329 330 PRs submitted by a core maintainer, regardless of size, only requires approval from one additional 331 maintainer. This ensures there are at least two maintainers who are aware of any significant PRs 332 introduced to the codebase. 333 334 | Label | Description | 335 | ----- | ----------- | 336 | `size/XS` | Anything less than or equal to 9 lines ignoring generated files. Only small amounts of manual testing may be required. | 337 | `size/S` | Anything greater than `size/XS` less than or equal to 29 lines ignoring the generated files. Only small amounts of manual testing may be required. | 338 | `size/M` | Anything greater than `size/S` less than or equal to 99 lines ignoring the generated files. Manual validation should be required. | 339 | `size/L` | Anything greater than `size/M` less than or equal to 499 lines ignoring the generated files. This should be thoroughly tested before merging and always requires 2 approvals. This also should be applied to anything that is a significant logic change. | 340 | `size/XL` | Anything greater than `size/L` less than or equal to 999 lines ignoring the generated files. This should be thoroughly tested before merging and always requires 2 approvals. This also should be applied to anything that is a significant logic change. | 341 | `size/XXL` | Anything greater than `size/XL`. This should be thoroughly tested before merging and always requires 2 approvals. This also should be applied to anything that is a significant logic change. |