upleb.uk

Public git repos — served from a NIP-34 GRASP relay at git.upleb.uk

summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorDanConwayDev <DanConwayDev@protonmail.com>2024-03-07 09:20:25 +0000
committerfiatjaf_ <fiatjaf@gmail.com>2024-04-17 17:46:34 -0300
commit0b62729e318497922822c39471ab31a869563ba5 (patch)
tree7c2589cffe1f5bd89a6b770d3ea58b1f97869980
parent8225a018c72c4d11b575ed4e57fa587d08c09027 (diff)
NIP-34: clarify cover letters
remove cover letters from 'possible things to be added later' and add a clarification that can they can be added through patches
-rw-r--r--34.md3
1 files changed, 2 insertions, 1 deletions
diff --git a/34.md b/34.md
index fefc7af..c6e7225 100644
--- a/34.md
+++ b/34.md
@@ -69,6 +69,8 @@ The first patch revision in a patch revision SHOULD include a NIP-10 `e` `reply`
69} 69}
70``` 70```
71 71
72The first patch in a series MAY be a cover letter in the format produced by `git format-patch`.
73
72## Issues 74## Issues
73 75
74Issues are Markdown text that is just human-readable conversational threads related to the repository: bug reports, feature requests, questions or comments of any kind. Like patches, these SHOULD be sent to the relays specified in that repository's announcement event's `"relays"` tag. 76Issues are Markdown text that is just human-readable conversational threads related to the repository: bug reports, feature requests, questions or comments of any kind. Like patches, these SHOULD be sent to the relays specified in that repository's announcement event's `"relays"` tag.
@@ -108,5 +110,4 @@ Replies are also Markdown text. The difference is that they MUST be issued as re
108 110
109- "status" kind (for letting people know a patch was merged or an issue was fixed or won't be fixed) 111- "status" kind (for letting people know a patch was merged or an issue was fixed or won't be fixed)
110- "branch merge" kind (specifying a URL from where to fetch the branch to be merged) 112- "branch merge" kind (specifying a URL from where to fetch the branch to be merged)
111- "cover letter" kind (to which multiple patches can refer and serve as a unifying layer to them)
112- inline file comments kind (we probably need one for patches and a different one for merged files) 113- inline file comments kind (we probably need one for patches and a different one for merged files)