1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
|
# Contributing to thin-edge.io
Thanks for taking the time to contribute to thin-edge.io!
Contributing is not limited to writing code and submitting a PR. Feel free to
submit an [issue](https://github.com/thin-edge/thin-edge.io/issues) or comment
on an existing one to report a bug, provide feedback, or suggest a new feature.
You can also join us on GitHub Discussions.
Of course, contributing code is more than welcome! If you're planning to submit
a PR to implement a new feature or fix a bug, please open an issue that explains
the change and the motivation for it.
If you are interested in contributing documentation, please note the following:
- Doc issues are labeled with the `doc` label.
- The thin-edge.io docs content is in the `docs/src/` directory.
[How to build from source.](./docs/src/BUILDING.md)
<br/>
<br/>
# Pull request and git commit guidance
## Opening PRs and organizing commits
PRs should generally address only 1 issue at a time. If you need to fix two
bugs, open two separate PRs. This will keep the scope of your pull requests
smaller and allow them to be reviewed and merged more quickly.
When possible, fill out as much detail in the pull request template as is
reasonable. Most important is to reference the GitHub issue that you are
addressing with the PR.
**NOTE:** GitHub has [a feature](https://docs.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword)
that will automatically close issues referenced with a keyword (such as "Fixes")
by a PR or commit once the PR/commit is merged. Don't use these keywords. We
don't want issues to be automatically closed. We want our testers to
independently verify and close them.
## Writing good commit messages
Git commit messages should explain the how and why of your change and be
separated into a brief subject line followed by a more detailed body. When in
doubt, follow this guide for good commit messages and you can’t go wrong:
[https://chris.beams.io/posts/git-commit/](https://chris.beams.io/posts/git-commit/).
## Reviewing, addressing feedback, and merging
Generally, pull requests need at least an approval from one maintainer to be
merged.
When addressing review feedback, it is helpful to the reviewer if additional
changes are made in new commits. This allows the reviewer to easily see the
delta between what they previously reviewed and the changes you added to address
their feedback. If applicable, the `git commit --fixup=<sha>` feature should be
used. These fixup commits should then be squashed (usually `git rebase -i
--autosquash main`) by the author of the PR after it passed review and before it
is merged.
Once a PR has the necessary approvals, it can be merged. Here’s how the merge should be handled:
- If the PR is a single logical commit, the merger should use the “Rebase and
merge” option. This keeps the git commit history very clean and simple and
eliminates noise from "merge commits."
- If the PR is more than one logical commit, the merger should use the “Create a
merge commit” option.
- If the PR consists of more than one commit because the author added commits to
address feedback, the commits should be squashed into a single commit (or more
than one logical commit, if it is a big feature that needs more commits). This
can be achieved by the “Squash and merge” option. If they do this, the merger
is responsible for cleaning up the commit message according to the previously
stated commit message guidance.
# Developers Certificate of Origin
Sign-Off and acceptance of the Developers Ceritificate of Origin (DCO) is
declared by using the option "-s" in
> git commit -s
which will automatically generate a sign-off statement in the form:
> Signed-off-by: Max Mustermann \<MaxM@example.com\>
By adding this sign-off statement, you are certifying:
```
Developer Certificate of Origin
Version 1.1
Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
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.
```
## Note on Privacy
Please note that this project and any contributions to it are public and that a
record of all contributions (including any personal information submitted with
it, including a sign-off) is maintained indefinitely and may be redistributed
consistent with this project or the open source license(s) involved.
In addition to [GitHub's privacy
statement](https://docs.github.com/en/github/site-policy/github-privacy-statement)
extracting personal data from these projects for any other use than maintaining
the projects and communication related to it is prohibited, explicitly
prohibited is extracting email addresses for unsolicited bulk mails.
If you'd like to keep your personal email address private, you can use a
GitHub-provided no-reply email address as your commit email address. You can
choose which verified email address to author changes with when you edit,
delete, or create files or merge a pull request on GitHub. If you enabled email
address privacy, then the commit author email address cannot be changed and is
\<username\>@users.noreply.github.com by default.
See [setting your commit email address on GitHub](https://docs.github.com/en/github/setting-up-and-managing-your-github-user-account/setting-your-commit-email-address#setting-your-commit-email-address-on-github).
In the upper-right corner of any page, click your profile photo, then click
**Settings**.
1. In the left sidebar, click **Emails**.
1. In "Add email address", type your email address and click **Add**.
1. Verify your email address.
1. In the "Primary email address" list, select the email address you'd like to
associate with your web-based Git operations.
1. To keep your email address private when performing web-based Git operations,
click **Keep my email address private**.
1. You can use the git config command to change the email address you associate
with your Git commits.
See [setting your commit email address in Git](https://docs.github.com/en/github/setting-up-and-managing-your-github-user-account/setting-your-commit-email-address#setting-your-commit-email-address-in-git).
1. Open Git Bash.
2. Set an email address in Git. You can use your GitHub-provided no-reply email
addressor any email address. >$ git config --global user.email
"email@example.com"
3. Confirm that you have set the email address correctly in Git:
>$ git config --global user.email <br>
>email@example.com
4. Add the email address to your account on GitHub, so that your commits are
attributed to you and appear in your contributions graph.
Release date: 2021-03-29
|
