On Mon, Jul 27, 2015 at 10:56:58AM -0400, Samantha N. Bueno wrote:
This contains patch submission guidelines for blivet, which are based on the kernel patch submission guidelines.
CONTRIBUTING | 268 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 268 insertions(+) create mode 100644 CONTRIBUTING
Should this go in docs/ instead? It would be useful if it showed up in the Sphinx docs and used its formatting.
diff --git a/CONTRIBUTING b/CONTRIBUTING new file mode 100644 index 0000000..281e301 --- /dev/null +++ b/CONTRIBUTING @@ -0,0 +1,268 @@ +0. Thanks to the kernel patch submission guidelines, which were used as a
- framework for creating this document.
- https://www.kernel.org/doc/Documentation/SubmittingPatches
+I. Source +=========
+A) Obtain a current source tree. +If you do not have a repository with the current source handy, use git to obtain +one. All installer-related projects can be found on the RH Installer project +page:
Probably want to point directly to the blivet repo too.
+III. Submitting Patches +=======================
- Acceptable formats for patch submission
- Email guidelines
- Pull Request guidelines
This should also mention bugzilla. I've been adding the pull request in a bz comment when moving it to POST for example. Contributors fixing a bug should do something similar or attach a git formatted patch to the bug.
- It is common convention to prefix path subject lines with [PATCH]. This
s/path/patch/
- makes clear that the message is a patch.
- ii. No MIME, no links, no compression, no attachments. Just plain text.
- The developers need to be able to read and comment on the changes you are
- submitting. It is important for a developer to be able to "quote" your
- changes, using standard e-mail tools, so that they may comment on specific
- portions of your code.
- For this reason, all patches should be submitting e-mail "inline". WARNING:
- Be wary of your editor's word-wrap corrupting your patch, if you choose to
- cut-n-paste your patch.
- Do not attach the patch as a MIME attachment, compressed or not.
Mention git send-email here. That's the cleanest way to get it onto the list.
Looks good other than those small things, thanks!