First off, thank you for considering contributing to snuffleupagus.
If you've noticed a bug or have a question, look at the faq and search the issue tracker to see if someone else has already created a ticket. If not, go ahead and make one!
If this is something you think you can fix, then fork snuffleupagus and create a branch with a descriptive name.
A good branch name would be (where issue #325 is the ticket you're working on):
git checkout -b 325-kill-sql-injections
Just type make coverage
or make debug
, the testsuite should be run
automatically.
Please add tests if you're fixing a bug or adding a new feature: we do have a high coverage (functions, lines and branches), and intend to keep it that way.
If your changes have introduced run-time failures in the test-suite, you can easily troubleshoot them by inspecting the files that php has generated for this purpose.
A nice trick is to edit the .sh
file to prepend gdb --args
to it before
launching it, in order to run the failing test inside GDB.
- Ensure the bug was not already reported by searching all issues.
- If you're unable to find an open issue addressing the problem, open a new one. Be sure to include a title and clear description, as much relevant information as possible, and a code sample or an executable test case demonstrating the expected behavior that is not occurring.
Your patch should follow the same conventions & pass the same code quality
checks as the rest of the project. We're using clang-format to
ensure a consistent code-style. Please run it with clang-format --style="{BasedOnStyle: google, SortIncludes: false}"
before committing, or even better, use a pre-commit hook.
At this point, you should switch back to your master branch and make sure it's up to date with our upstream master branch:
git remote add upstream git@github.com:jvoisin/snuffleupagus.git
git checkout master
git pull upstream master
Then update your feature branch from your local copy of master, and push it!
git checkout 325-kill-sql-injections
git rebase master
git push --set-upstream origin 325-kill-sql-injections
Finally, go to GitHub and make a Pull Request :D
Travis CI will run our test suite against all supported PHP versions. We care about quality, so your PR won't be merged until all tests pass. It's unlikely, but it's possible that your changes pass tests in one PHP version but fail in another. In that case, you'll have to setup your development environment to use the problematic PHP version, and investigate what's going on!
If a maintainer asks you to "rebase" your PR, they're saying that a lot of code has changed, and that you need to update your branch so it's easier to merge.
To learn more about rebasing in Git, there are a lot of good resources but here's the suggested workflow:
git checkout 325-kill-sql-injections
git pull --rebase upstream master
git push --force-with-lease 325-kill-sql-injections
A PR can only be merged into master by a maintainer if:
- It is passing CI.
- It has been approved by at least one maintainer. If it was a maintainer who opened the PR, only one extra approval is needed.
- It has no requested changes.
- It is up to date with current master.
Any maintainer is allowed to merge a PR if all of these conditions are met.
Maintainers need to do the following to push out a release:
- Make sure that all pending and mergeable pull requests are in
- Close the corresponding milestone
- Run
valgrind
(by adding a-m
after the-q
in the Makefile) and check that everything is ok. Don't mind the python-related issues. - Run
cd src; phpize; ./configure --enable-snuffleupagus --enable-debug; scan-build make
and fix the possible issues. - Update the
src/php_snuffleupagus.h
according to semantic versioning - Update the changelog page in the documentation
- Update the Debian changelog in
./debian/changelog
withcd debian; dch
- Commit the result
- Clean up the folder
make clean; git clean -xdf
- Create a tag for the release:
git tag -s v$MAJOR.$MINOR.$PATCH -m "v$MAJOR.$MINOR.$PATCH"
git push --tags
git push origin master
- Wait for the CI on the new tag branch to finish
- Create the release on github
- Add the freshly built Debian packages from the CI to the release
- Do the secret release dance