Commit b810db39 authored by Virgile Prevosto's avatar Virgile Prevosto
Browse files

[contributing] update CONTRIBUTING.md

parent e03c8044
......@@ -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.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment