1## Contributing
2
3First off, thank you for considering contributing to snuffleupagus.
4
5### 1. Where do I go from here?
6
7If you've noticed a bug or have a question,
8look at the [faq](https://snuffleupagus.readthedocs.io/faq.html) and
9[search the issue tracker](https://github.com/jvoisin/snuffleupagus/issues)
10to see if someone else has already created a ticket. If not, go ahead and
11[make one](https://github.com/jvoisin/snuffleupagus/issues/new)!
12
13### 2. Fork & create a branch
14
15If this is something you think you can fix,
16then [fork snuffleupagus](https://help.github.com/articles/fork-a-repo) and
17create a branch with a descriptive name.
18
19A good branch name would be (where issue #325 is the ticket you're working on):
20
21```sh
22git checkout -b 325-kill-sql-injections
23```
24
25### 3. Get the test suite running
26
27Just type `make coverage` or `make debug`, the testsuite should be run
28automatically.
29
30Please add tests if you're fixing a bug or adding a new feature: we do have a
31[high coverage](https://coveralls.io/github/jvoisin/snuffleupagus?branch=master)
32(functions, lines and branches), and intend to keep it that way.
33
34#### 3.3 Debugging failures in the test suite
35
36If your changes have introduced run-time failures in the test-suite, you can
37easily troubleshoot them by inspecting the files that
38[php has generated](https://qa.php.net/write-test.php#analyzing-failing-tests)
39for this purpose.
40
41A nice trick is to edit the `.sh` file to prepend `gdb --args` to it before
42launching it, in order to run the failing test inside GDB.
43
44
45### 4. Did you find a bug?
46
47* **Ensure the bug was not already reported** by
48  [searching all issues](https://github.com/jvoisin/snuffleupagus/issues?q=).
49* If you're unable to find an open issue addressing the problem,
50  [open a new one](https://github.com/jvoisin/snuffleupagus/issues/new).
51  Be sure to include a **title and clear description**,
52  as much relevant information as possible, and a **code sample**
53  or an **executable test case** demonstrating the expected behavior that is not
54  occurring.
55
56
57### 5. Get the style right
58
59Your patch should follow the same conventions & pass the same code quality
60checks as the rest of the project. We're using [clang-format](http://clang.llvm.org/docs/ClangFormat.html) to
61ensure a consistent code-style. Please run it with `clang-format --style="{BasedOnStyle: google, SortIncludes: false}"`
62before committing, or even better, use a [pre-commit hook](https://github.com/andrewseidl/githook-clang-format).
63
64### 6. Make a Pull Request
65
66At this point, you should switch back to your master branch and make sure it's
67up to date with our upstream master branch:
68
69```sh
70git remote add upstream git@github.com:jvoisin/snuffleupagus.git
71git checkout master
72git pull upstream master
73```
74
75Then update your feature branch from your local copy of master, and push it!
76
77```sh
78git checkout 325-kill-sql-injections
79git rebase master
80git push --set-upstream origin 325-kill-sql-injections
81```
82
83Finally, go to GitHub and [make a Pull Request](https://help.github.com/articles/creating-a-pull-request) :D
84
85Travis CI will [run our test suite](https://travis-ci.org/jvoisin/snuffleupagus)
86against all supported PHP versions. We care about quality, so your PR won't be
87merged until all tests pass. It's unlikely, but it's possible that your changes
88pass tests in one PHP version but fail in another. In that case, you'll have to
89setup your development environment to use the problematic PHP version, and
90investigate what's going on!
91
92### 7. Keeping your Pull Request updated
93
94If a maintainer asks you to "rebase" your PR, they're saying that a lot of code
95has changed, and that you need to update your branch so it's easier to merge.
96
97To learn more about rebasing in Git, there are a lot of [good](http://git-scm.com/book/en/Git-Branching-Rebasing)
98[resources](https://help.github.com/articles/interactive-rebase) but here's the suggested workflow:
99
100```sh
101git checkout 325-kill-sql-injections
102git pull --rebase upstream master
103git push --force-with-lease 325-kill-sql-injections
104```
105
106### 8. Merging a PR (maintainers only)
107
108A PR can only be merged into master by a maintainer if:
109
1101. It is passing CI.
1112. It has been approved by at least one maintainer. If it was a maintainer who
112   opened the PR, only one extra approval is needed.
1133. It has no requested changes.
1144. It is up to date with current master.
115
116Any maintainer is allowed to merge a PR if all of these conditions are met.
117
118### 9. Shipping a release (maintainers only)
119
120Maintainers need to do the following to push out a release:
121
1221. Make sure that all pending and mergeable pull requests are in
1232. Close the corresponding
124	 [milestone](https://github.com/jvoisin/snuffleupagus/milestones)
1252. Run `valgrind` (by adding a `-m` after the `-q` in the Makefile) and check that everything is ok.
126   Don't mind the python-related issues.
1272. Run `cd src; phpize; ./configure --enable-snuffleupagus --enable-debug; scan-build make`
128   and fix the possible issues.
1293. Update the `src/php_snuffleupagus.h` according to [semantic versioning](https://semver.org/)
1304. Update the changelog page in the documentation
1315. Update the Debian changelog in `./debian/changelog` with `cd debian; dch`
1326. Commit the result
1337. Clean up the folder `make clean; git clean -xdf`
1348. Create a tag for the release:
135
136  ```sh
137  git tag -s v$MAJOR.$MINOR.$PATCH -m "v$MAJOR.$MINOR.$PATCH"
138  git push --tags
139	git push origin master
140  ```
141
1429. Build the debian package with `make debian`
14310. Create the [release on github](https://github.com/jvoisin/snuffleupagus/releases)
14411. Add the freshly built Debian package to the release
14512. Publish a [tweet](https://twitter.com/sp_php)
14613. Do the *secret release dance*
147