adam/yr
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs: Typos

Browse source 
Signed-off-by: Tim Hårek Andreassen <tim@harek.no>
This commit is contained in:
Tim Hårek Andreassen 2024-10-03 19:52:46 +02:00
parent 112ba8795d
commit 18681cffee
No known key found for this signature in database
GPG key ID: E59C7734F0E10EB5
1 changed files with 6 additions and 9 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

15
CONTRIBUTING.md
View file

@ -27,13 +27,13 @@ commits). Follow these general rules:
- Limit the first line (title) of the commit message to 60 characters.
- Use a short prefix for the commit title for readability with `git log --oneline`.
- Use the body of the commit message to actually explain what your patch does
and why it is useful. Even if your patch is a one line fix, the description
and why it is useful. Even if your patch is an one line fix, the description
is not limited in length and may span over multiple paragraphs. Use proper
English syntax, grammar and punctuation.
- Address only one issue/topic per commit.
- Describe your changes in imperative mood, e.g. _"make xyzzy do frotz"_
instead of _"[This patch] makes xyzzy do frotz"_ or _"[I] changed xyzzy to do
frotz"_, as if you are giving orders to the codebase to change its behaviour.
frotz"_, as if you are giving orders to the codebase to change its behavior.
- If you are fixing a ticket, use appropriate
[commit trailers](https://man.sr.ht/git.sr.ht/#referencing-tickets-in-git-commit-messages).
- If you are fixing a regression introduced by another commit, add a `Fixes:`
@ -43,9 +43,6 @@ commits). Follow these general rules:
There is a great reference for commit messages in the
[Linux kernel documentation](https://www.kernel.org/doc/html/latest/process/submitting-patches.html#describe-your-changes).
Before sending the patch, you should configure your local clone with sane
defaults using `deno task setup:srht`:
And send the patch to the mailing list ([step-by-step
instructions][git-send-email-tutorial]):
@ -58,7 +55,7 @@ others. They will indicate their approval by replying to your patch with
a [Tested-by, Reviewed-by or Acked-by][linux-review] (see also: [the git
wiki][git-trailers]) trailer. For example:
You can follow the review process via email and on the [web ui][web-ui].
You can follow the review process via email and on the [web UI].
Wait for feedback. Address comments and amend changes to your original commit.
Then you should send a v2 (and maybe a v3, v4, etc.):
@ -67,7 +64,7 @@ Then you should send a v2 (and maybe a v3, v4, etc.):
git send-email --annotate v2 -1
```
Be polite, patient and address _all_ of the reviewers' remarks. If you disagree
Be polite, patient and address _all_ the reviewers' remarks. If you disagree
with something, feel free to discuss it.
Once your patch has been reviewed and approved (and if the maintainer is OK
@ -75,9 +72,9 @@ with it), it will be applied and pushed.
IMPORTANT: Do NOT use `--in-reply-to` when sending followup versions of a patch
set. It causes multiple versions of the same patch to be merged under v1 in the
[web ui][web-ui]
[web UI]
[web-ui]: https://lists.sr.ht/~timharek/yr/patches
[web UI]: https://lists.sr.ht/~timharek/yr/patches
[git-send-email-tutorial]: https://git-send-email.io/
[git-trailers]: https://git.wiki.kernel.org/index.php/CommitMessageConventions
[linux-review]: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes