Webrtc/checkin policy

Ok, it's not really a "policy", but if you're new to the project and looking to checkin WebRTC code, here are some steps we've captured to make checkin as smooth as possible.

Either before or after you have the patch reviewed, please verify that your patch doesn't break our automated WebRTC tests. This explains how you can do that.

If you're in a hurry, but want to make sure the mochitests/crashtests are happy, you can just run mochitests and crashtests on your machine (Step 1). Otherwise, you can skip to step 2 and push your patch to Try on the Alder branch. If you do both, you can have maximum confidence that your patch won't cause problems with mochitests/crashtests.

1. Run mochitests/crashtests on your machine

You'll want to (clobber) rebuild Firefox with the following environment variable exported, e.g. in your mozconfig file:

   export MOZ_WEBRTC_LEAKING_TESTS=1  (to run leaking mochitests)
   export MOZ_WEBRTC_TESTS=1          (to run signaling unit tests)

This is necessary because most of our tests are disabled by default currently due to different leaks. (We'll be fixing them soon.) When the build is ready, please run the following tests:

   ${OBJ_DIR}/media/webrtc/signaling/test/*          (run each individual test)
   ${OBJ_DIR}/media/mtransport/test/*                (run each individual test)

   ./mach mochitest-plain dom/media/tests/mochitest  (runs all mochitests)
   ./mach crashtest dom/media/tests/crashtests       (runs all crashtests)

If you need to run mochtests or crashtests in the debugger, use the --debugger flag, like so:

   ./mach mochitest-plain dom/media/tests/mochitest --debugger=gdb
   ./mach crashtest dom/media/tests/crashtests --debugger=gdb

If you get errors trying to run the standalone tests, you might need to set your dynamic library path:

   export LD_LIBRARY_PATH=${OBJ_DIR}/dist/lib     (Linux)
   export DYLD_LIBRARY_PATH=${OBJ_DIR}/dist/lib   (OS X)

NOTE: If you find test failures or crashes, please investigate and fix the problems if you can or reach out for help in #media. Typically jesup or mreavy in #media can help or find someone to help. If neither of them is there (pretty rare!), just ask your question in the channel. Someone will help. Please don't commit if mochitests or crashtests fail; it is likely you'll just be asked to back out the patch.

If you have no failures on your machine, then your code is probably fine to check in and you can skip to Step 3. If you want to have maximum confidence, then send it to Try as explained in Step 2. Try is your friend.  :-) However, Step 2 (pushing to Try) could take a while (perhaps a couple of hours).

You may be able to use run-webrtc-tests.sh to automate running all of these tests on your local machine.

2. Push your patch on Alder to Try

If you're not in a hurry and pretty sure it will "just work", you can skip Step 1 and apply your patch to a pull of the Alder tree and push to Try from there. Alder builds will always run the tests, and they have leak checks disabled for now. (Our tests are disabled on mozilla-central until all the leaks are plugged.)

Push to try with a commit message like: "try: -b do -p all -u all -t none" (if you want different try options, you might find the TryChooser to be useful: http://trychooser.pub.build.mozilla.org/).

NOTE (same as note in Step 1): If your Try push fails, please investigate and fix the problems if you can or reach out for help in #media. Typically jesup or mreavy in #media can help or find someone to help. If neither of them is there (pretty rare!), just ask your question in the channel. Someone will help. Please don't commit if mochitests or crashtests fail; it is likely you'll just be asked to back out the patch.

3. Land the Patch

If you have successfully completed Step 1 and/or Step 2 and your patch has gotten an r+ (successful review), you can land it on mozilla-inbound or directly on mozilla-central with confidence that it should work.  ;-)

Most importantly: Thanks so much for contributing to WebRTC! It is much appreciated!!