Document the procedure for advancing the ooni-backend submodule.

[defuse]

The process should be:

• First, test with the newest Ooni commit.
• Then, advance the submodule.

I tried to do this by checking out master in the submodule before building the rpm, but I ended up getting the submodule version anyway. Not sure why that is.

[defuse]

Note that #41 depends on this.

[defuse]

Note that #41 depends on this.

[defuse]

Here's how I did it:

1. Clone ooni-support
2. Create a new branch.
3. On the new branch, cd into the ooni-backend directory and checkout the revision you want, i.e. git checkout master.
4. Change back to the ooni-support directory, look at git diff and notice that the revision of the submodule has changed. Commit.
5. On the M-Lab sliver, follow the README, except after cloning, git checkout the branch you created in step 2, then run git submodule update. This will bring the ooni-backend submodule to the commit that was commited in step 4.
6. Proceed as normal.

Edit: I forgot something obvious in step 3, which is to fetch/pull so your master is actually the most recent master!

[defuse]

This is related to #33, but isn't exactly the same. This is about "What do we actually do to this repository to make the new Ooni version available through it?" The other is about acceptance criteria.

[defuse]

I think the steps I left in the previous comment are close enough. The only thing I might add is to create a git tag so that everyone agrees on which past ooni-support / ooni-probe revision combinations were used.

[defuse]

Note that this policy isn't specific to Ooni, it actually applies to all experiments that use submodules. So the documentation should go in another repository like https://github.com/m-lab-tools/package. The important new step is the fact that the branch should be tested before getting tagged. ;)