[gcr] Rename HACKING to CONTRIBUTING.md

[Niels De Graef <nielsdg src gnome org>]

commit f1f1a85026f04f32a53269c104b72f187f1c5b47
Author: Niels De Graef <nielsdegraef gmail com>
Date:   Sat Jan 16 11:40:41 2021 +0100

    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.

 CONTRIBUTING.md | 162 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 HACKING         | 142 -------------------------------------------------
 2 files changed, 162 insertions(+), 142 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.