[Cluster-devel] [PATCH] gfs2-utils: Add a doc on contributing

[Steven Whitehouse]

Hi,

Looks good,

Steve.

On Tue, 2012-12-18 at 14:04 +0000, Andrew Price wrote:
> Add README.contributing to cover some common questions from
> contributors.
> 
> Signed-off-by: Andrew Price <anprice at redhat.com>
> ---
>  doc/Makefile.am         |  1 +
>  doc/README.contributing | 65 +++++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 66 insertions(+)
>  create mode 100644 doc/README.contributing
> 
> diff --git a/doc/Makefile.am b/doc/Makefile.am
> index 05ec222..6a70f82 100644
> --- a/doc/Makefile.am
> +++ b/doc/Makefile.am
> @@ -6,4 +6,5 @@ dist_doc_DATA		= gfs2.txt \
>  			  COPYING.applications \
>  			  COPYING.libraries \
>  			  COPYRIGHT \
> +			  README.contributing \
>  			  README.licence
> diff --git a/doc/README.contributing b/doc/README.contributing
> new file mode 100644
> index 0000000..d669271
> --- /dev/null
> +++ b/doc/README.contributing
> @@ -0,0 +1,65 @@
> +Contributing to gfs2-utils
> +--------------------------
> +
> +Here are some brief guidelines to follow when contributing to gfs2-utils.
> +
> +Translations
> +------------
> +
> +We use the Transifex translation service:
> +
> +    https://transifex.com/projects/p/gfs2-utils/
> +
> +See the documentation there for submitting translations.
> +
> +Patches
> +-------
> +
> +We don't dictate any particular coding style but please try to use a style
> +consistent with the existing code. If in doubt, the Linux kernel coding style
> +document is a good guideline:
> +
> +    http://www.kernel.org/doc/Documentation/CodingStyle
> +
> +We use git for managing our source code and we assume here that you're familiar
> +with git. Patches should apply cleanly to the latest master branch of
> +gfs2-utils.git
> +
> +    http://git.fedorahosted.org/cgit/gfs2-utils.git
> +
> +For ease of review and maintenance each of your patches should address a single
> +issue and if there are multiple issues please consider spreading your work over
> +several patches. Ideally none of the individual patches should break the build.
> +
> +We value good commit logs, which should be of the form:
> +
> +    component: short patch summary
> +
> +    Longer description wrapped at approx. 72 columns explaining the problem the
> +    patch addresses and how the patch addresses it.
> +
> +    Signed-off-by: Your Name <youremail at example.com>
> +
> +The "component" should be the name of the tool or the part of the code which
> +the patch touches. As we share a mailing list with several projects it should
> +make clear that it's a gfs2-utils patch. Some examples:
> +
> +Bad short logs:
> +
> +    Fix a bug
> +    Add a test
> +
> +Good short logs:
> +
> +    fsck.gfs2: Fix a null pointer dereference in foo
> +    gfs2-utils: Add a test for lgfs2_do_stuff
> +
> +Be sure to reference any relevant bug reports in your long description, e.g.
> +
> +    Ref: rhbz#012345
> +    Fixes: rhbz#98765
> +
> +Please send patches to <cluster-devel at redhat.com>. We recommend using
> +`git format-patch' to generate patch emails from your commits and `git
> +send-email' for sending them to the list. See the git documentation for
> +details.