[master][blivet] Add CONTRIBUTING file to blivet.
Brian C. Lane
bcl at redhat.com
Tue Jul 28 19:03:11 UTC 2015
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:
> +
> + http://github.com/rhinstaller/
> +
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!
--
Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)
More information about the anaconda-patches
mailing list