Contributing to gfs2-utils
Here are some brief guidelines to follow when contributing to gfs2-utils.
We use the Zanata translation service:
See the documentation there for submitting translations.
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:
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
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 <firstname.lastname@example.org>
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.
Please send patches to <email@example.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