[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