[librsvg] CONTRIBUTING.md: Document the CI infrastructure a bit and cargo fmt

[Federico Mena Quintero <federico src gnome org>]

commit 232f655107a5ef86a0c08a5fc5fc4542031ce69c
Author: Federico Mena Quintero <federico gnome org>
Date:   Tue Mar 20 09:22:00 2018 -0600

    CONTRIBUTING.md: Document the CI infrastructure a bit and cargo fmt

 CONTRIBUTING.md | 129 ++++++++++++++++++++++++++++++++++++++++++--------------
 1 file changed, 98 insertions(+), 31 deletions(-)
---
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 891bce16..bfb104cf 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -7,7 +7,7 @@ contributing to librsvg, and we appreciate all of them.
 * [Source repository](#source-code)
 * [Reporting bugs](#reporting-bugs)
 * [Feature requests](#feature-requests)
-* [Merge requests](#merge-requests)
+* [Hacking on librsvg](#hacking-on-librsvg)
 
 There is a **code of conduct** for contributors to librsvg; please see the
 file [`code-of-conduct.md`][coc].
@@ -33,6 +33,9 @@ If you need to publish a branch, feel free to do it at any
 publically-accessible Git hosting service, although gitlab.gnome.org
 makes things easier for the maintainers of librsvg.
 
+To work on the source code, you may find the "[Hacking on
+librsvg](#hacking-on-librsvg)" section helpful.
+
 ## Reporting bugs
 
 Please report bugs at https://gitlab.gnome.org/GNOME/librsvg/issues
@@ -62,36 +65,7 @@ directed there.
 It is especially helpful if you file bug for a feature request along
 with a sample SVG file.
 
-## Merge requests
-
-### Creating a merge request
-
-You may create a forked version of librsvg in [GNOME's Gitlab
-instance][gitlab], or any other publically-accesible Git hosting
-service.  You can register an account there, or log in with your
-account from other OAuth services.
-
-Note that the maintainers of librsvg only get notified about merge
-requests (or pull requests) if your fork is in
-[gitlab.gnome.org][gitlab].
-
-For technical reasons, the maintainers of librsvg do not get
-automatically notified if you submit a pull request through the GNOME
-mirror in Github.  [Please contact the maintainer][maintainer] directly if you
-have a pull request there or a branch that you would like to
-contribute.
-
-### Test suite
-
-Please make sure that the test suite passes with the changes in your
-branch.  The easiest way to run all the tests is to go to librsvg's
-toplevel directory and run `make check`.  This will run both the small
-unit tests and the black box tests in the `librsvg/tests` directory.
-
-If you need to add new tests (you should, for new features, or for
-things that we weren't testing!), or for additional information on how
-the test suite works, please see the file
-[`tests/README.md`][tests-readme].
+## Hacking on librsvg
 
 ### Working on the source
 
@@ -111,6 +85,82 @@ Please read the file [`ARCHITECTURE.md`][arch]; this describes the
 overall flow of the source code, so hopefully it will be easier for
 you to navigate.
 
+### Taking advantage of Continuous Integration
+
+If you fork librsvg in `gitlab.gnome.org` and push commits to your
+forked version, the Continuous Integration machinery (CI) will run
+automatically.
+
+A little glossary:
+
+* ***Continuous Integration (CI)*** - A tireless robot that builds
+  librsvg on every push, and runs various kinds of tests.
+  
+* ***Pipeline*** - A set of ***jobs*** that may happen on every push.
+  Every pipeline has ***stages*** of things that get run.  You can
+  [view recent
+  pipelines](https://gitlab.gnome.org/GNOME/librsvg/pipelines) and
+  examine their status.
+  
+* ***Stages*** - Each stage runs some kind of test on librsvg, and
+  depends on the previous stages succeeding.  We have a *Test* stage
+  that just builds librsvg as quickly as possible and runs its test
+  suite.  If that succeeds, then it will go to a *Lint* stage which
+  runs `rustfmt` to ensure that the coding style remains consistent.
+  Finally, there is a `Cross_distro` stage that tries to build/test
+  librsvg on various operating systems and configurations.
+  
+* ***Jobs*** - You can think of a job as "something that runs in a
+  specific container image, and emits a success/failure result".  For
+  example, the `Test` stage runs a job in a fast Fedora container.
+  The `Lint` stage runs `rustfmt` in a Rust-specific container that
+  always contains a recent version of `rustfmt`.  Distro-specific jobs
+  run on container images for each distro we support.
+  
+The default CI pipeline for people's branches is set up to build your
+branch and to run the test suite and lints.  If any tests fail, the
+pipeline will fail and you can then examine the job's build
+artifacts.  If the lint stage fails, you will have to reindent your
+code.
+
+***Automating the code formatting:*** You may want to enable a
+[client-side git
+hook](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks) to run
+`rustfmt` before you can commit something; otherwise the `Lint` stage
+of CI pipelines will fail:
+
+1. `cd librsvg`
+
+1. `mv .git/hooks/pre-commit.sample .git/hooks/pre-commit`
+
+1. Edit `.git/hooks/pre-commit` and put in one of the following
+   commands:
+
+  * If you want code reformatted automatically, no questions asked:
+    `cargo fmt --write-mode=overwrite`
+
+  * If you want to examine error if rustfmt doesn't like your indentation,
+    but don't want it to make changes on its own:
+    `cargo fmt --write-mode=diff`
+
+### Test suite
+
+Please make sure that the test suite passes with the changes in your
+branch.  The easiest way to run all the tests is to go to librsvg's
+toplevel directory and run `make check`.  This will run both the small
+unit tests and the black box tests in the `librsvg/tests` directory.
+
+If you need to add new tests (you should, for new features, or for
+things that we weren't testing!), or for additional information on how
+the test suite works, please see the file
+[`tests/README.md`][tests-readme].
+
+In addition, the CI machinery will run librsvg's test suite
+automatically when you push some commits.  You can tweak what happens
+during CI for your branch in the [`.gitlab-ci.yml`
+file](.gitlab-ci.yml) — for example, if you want to enable
+distro-specific tests to test things on a system that you don't have.
+
 ### Testing changes
 
 The most direct way to test a change is to have an example SVG file
@@ -130,6 +180,23 @@ have things working (or before even writing code, if you like
 test-driven development), so we can avoid regressions later.  The test
 suite is documented in [`tests/README.md`][tests-readme].
 
+### Creating a merge request
+
+You may create a forked version of librsvg in [GNOME's Gitlab
+instance][gitlab], or any other publically-accesible Git hosting
+service.  You can register an account there, or log in with your
+account from other OAuth services.
+
+Note that the maintainers of librsvg only get notified about merge
+requests (or pull requests) if your fork is in
+[gitlab.gnome.org][gitlab].
+
+For technical reasons, the maintainers of librsvg do not get
+automatically notified if you submit a pull request through the GNOME
+mirror in Github.  [Please contact the maintainer][maintainer] directly if you
+have a pull request there or a branch that you would like to
+contribute.
+
 ### Testing performance-related changes
 
 You can use the [rsvg-bench] tool to benchmark librsvg.  It lets you