Every open source project has its own rules, I found the choices taken in Libvpx interesting enough to write them down (and possibly help newcomers with some shortcuts).
The coding style is strongly enforced, the CI system will bounce your code if it doesn’t adhere to the style.
This constraint is enforced through a clang-format ruleset.
# clang-format -i what/I/m/working/on.c
Works no matter what.
New code should have its testcase, if it isn’t already covered.
Libvpx uses gtest and it has a quite decent test coverage. A full run of the tests can take a large chunk of time, if you are working on specific code (e.g. dsp functions), is easy to run only the tests you care about like this:
# ./test_libvpx --gtest_filter="*pattern*with*globs"
The current system does not double as benchmarking tool, so you are quite on your own if you are trying to speed up some parts.
Adding brand new tests more annoying than it should since gtest is quite bloated, updating a test to cover a variant is quite painless though.
Gerrit and Jenkins defaults are quite clunky, so they Libvpx maintainer definitely invested some time to get them in a better shape.
Once you registered and set the hook to tag your commits sending a set boils down to:
# git push https://chromium-review.googlesource.com/webm/libvpx HEAD:refs/for/master
Comments and reports end up in your mailbox, spamming it a lot (expect about 5-6 emails per commit). You have to use the web interface to have decent interaction and luckily PolyGerrit isn’t terrible at all (just make sure your replies gets sent since it has the tendency of keeping them in draft mode).