From b810db3970942f088b0f5838c5d6ccd35eaf34be Mon Sep 17 00:00:00 2001 From: Virgile Prevosto <virgile.prevosto@m4x.org> Date: Wed, 30 Oct 2019 15:57:12 +0100 Subject: [PATCH] [contributing] update CONTRIBUTING.md --- CONTRIBUTING.md | 32 ++++++++++++++++++++------------ 1 file changed, 20 insertions(+), 12 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 77cd29c88da..e48e4d69931 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -10,9 +10,10 @@ There are several ways to participate in the Frama-C project: the [Frama-C-discuss mailing list](https://lists.gforge.inria.fr/mailman/listinfo/frama-c-discuss); -- Reporting bugs (via - [Github issues](https://github.com/Frama-C/Frama-C-snapshot/issues)) or the - [Mantis BTS](https://bts.frama-c.com); +- Reporting bugs, via + [Github issues](https://github.com/Frama-C/Frama-C-snapshot/issues) + (preferred) or the + [Mantis BTS](https://bts.frama-c.com) (older BTS); - [Submitting bug fixes, improvements, and features](#submitting-bug-fixes-improvements-and-features) via Github pull requests; @@ -49,7 +50,8 @@ To fit this workflow, we recommend to: 3. Clone the forked Frama-C snapshot repository on your computer; -4. Create and switch in a dedicated branch which should follow the following convention: +4. Create and switch to a dedicated branch. We suggest the following + naming convention: - `bugfix/username/short-description` for bug fixes (correcting an incorrect behaviour); - `improv/username/short-description` for improvements (making even better a @@ -60,12 +62,13 @@ To fit this workflow, we recommend to: the [coding conventions](#coding-conventions); 6. Optionally locally add non-regression test cases to the appropriate - subdirectory in `./tests/`. The + subdirectory in `./tests/`. The `hello` tutorial in the [plug-in developer manual](http://frama-c.com/download/frama-c-plugin-development-guide.pdf) - exemplifies the use of the dedicated `ptests` tool used by Frama-C developers - in its `hello` tutorial and provides a documentation of it in a full section. + provides an example of the use of the dedicated `ptests` + tool used by Frama-C developers. The full documentation for `ptests` is also + present later in the same manual. You can also provide the non-regression test case in the Github issue - discussion and we will integrate it). + discussion and we will integrate it. 7. Check for unexpected changes (in particular spaces and tabulations); @@ -87,6 +90,10 @@ To fit this workflow, we recommend to: `Frama-C/Frama-C-snapshot` and the base as `master` while the head fork should be yours and the compare should be your chosen branch name. +12. If needed (i.e. you didn't already do that and your contribution is + not trivial in the sense of [this document](TCA.md), please don't forget + to sign the [Contributor's Licence Agreement](CLA.md) + For convenience, we recall the typical `git` commands to be used through these steps: ```shell git clone https://github.com/<username>/Frama-C-snapshot.git @@ -137,16 +144,17 @@ as newer releases are made available, we recommend the following workflow: about your contribution to the Frama-C ecosystem. Well done! The main advantage of this way to proceed is the delegation to OPAM of the task -of keeping consistent Frama-C versions and dependencies. - +of checking the consistency of your plug-in against +Frama-C versions (and other OCaml dependencies if any). Coding conventions ================== -- Use [ocp-indent](https://github.com/OCamlPro/ocp-indent) to indent files; +- Use [ocp-indent](https://github.com/OCamlPro/ocp-indent), v1.7.0 +to indent OCaml source files; - Avoid trailing whitespaces; - Avoid using tabs; -- Strive to keep within 80 characters per line. \ No newline at end of file +- Strive to keep within 80 characters per line. -- GitLab