diff options
author | Niels De Graef <nielsdegraef@gmail.com> | 2021-01-16 11:40:41 +0100 |
---|---|---|
committer | Niels De Graef <nielsdegraef@gmail.com> | 2021-01-16 11:40:41 +0100 |
commit | f1f1a85026f04f32a53269c104b72f187f1c5b47 (patch) | |
tree | bd5e38598b346db4bbbdaa44048f24c350c58d06 /CONTRIBUTING.md | |
parent | 9117536d70f47db58cad983aad4c7cab3aa85538 (diff) | |
download | gcr-f1f1a85026f04f32a53269c104b72f187f1c5b47.tar.gz |
Rename HACKING to CONTRIBUTING.md
This makes it show up in the GitLab UI, and is a bit more user-friendly
as the markdown will be rendered.
Diffstat (limited to 'CONTRIBUTING.md')
-rw-r--r-- | CONTRIBUTING.md | 162 |
1 files changed, 162 insertions, 0 deletions
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 0000000..52893e5 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,162 @@ +Contributing to GCR, GCK libraries +================================== + +Code merging +------------ +This is the work flow for modifying the gcr repository: + +1. File a bug for the given flaw or feature (if it does not already exist) at + https://gitlab.gnome.org/GNOME/gcr/issues. + +2. Create a fork of the main repository on gitlab.gnome.org (if you haven't + already) and commit your work there. + +3. If this is a non-trivial flaw or feature, write test cases. We won't accept + significant changes without adequate test coverage. + +4. Write code to fix the flaw or add the feature. In the case that tests are + necessary, the new tests must pass consistently. + +5. All code must follow the project coding style (see below). + +6. Make a Merge Request from your fork to the main gcr repository. + +7. The project must remain buildable with all meson options and pass all + tests on all platforms. It should also pass the CI. + +8. Rework your code based on suggestions in the review and submit new patches. + Return to the review step as necessary. + +9. Finally, if everything is reviewed and approved, a maintainer will merge it + for you. Thanks! + + +Repository Structure +-------------------- +* egg: Various bits of code shared with other modules (private) +* gck: A public library for accessing PKCS#11 modules. +* gcr: A public library for bits of crypto and parsing etc... +* ui: A public library that provides a GTK UI for several objects in gcr. +* schema: Desktop settings schemas for crypto stuff +* testing: Testing CA, gnupg and other mock setups +* po: Contains translation files + +Coding style +------------ +Our coding style is very similar to the linux coding style: + + http://lxr.linux.no/linux/Documentation/CodingStyle + ++ Space between function name and parentheses. + +``` +my_function_call (arg1, arg2); +``` + +* Braces on the same line as conditional with spaces around braces: + +``` +if (test) { + do_y (); + do_z (); +} + +switch (value) { +case CONSTANT: + do_z (); + break; +default: + break; +} +``` + +* Braces around functions on a separate line from function name, + return value on a separate line, arguments on separate lines. + +``` +static void +my_special_function (int arg1, + int arg2) +{ + /* body of function */ +} +``` + +* Don't use braces unnecessarily: + +``` + if (test) + do_this_thing (); +``` + +* But use braces here, when one section has more than a line: + +``` + if (test) { + do_this_thing (); + } else { + do_other_thing (); + smile_nicely (); + } +``` + +* Use of tabs for 8 char indent. + +``` +------->if (test) { +------->------->Value; +------->------->Value; +------->} +``` + +* No trailing whitespace on lines. + +* The '*' in a pointer declaration belongs with the variable name: + +``` + char *name; +``` + ++ Extra long wrapped lines should wrap to function opening brace + using spaces past indentation point. + +``` +------>my_function_call ("this is a very long argument here", +------> "wrapped argument is indented with spaces"); +``` + +* Function names are in lower case with _ separators. + +``` +this_is_a_long_function_name (); +``` + +* Constants are all in upper case with _ separators. + +``` +THIS_IS_A_CONSTANT +``` + ++ Structures should be typedefed to avoid saying 'struct' and names + are CamelCase: + +``` +ThisIsAStruct +``` + +* One line comments should look like: + +``` +/* This is a one line comment */ +``` + +* Multi line comments should look like: + +``` +/* + * This is a multiline comment. + * And it has a useless second line. + */ +``` + +When in doubt, adapt to the style of the code around your patch. |