Title: Code Contributions

Slug: code-contributions

[reviews.imfreedom.org](https://reviews.imfreedom.org).

There are a few things you'll need to set up to be able to submit a code

review to these projects. This includes installing

[Mercurial](https://www.mercurial-scm.org/)

configuration.

The recommended way to install RBTools is via pip and can be done with the

following command.

```sh

```

Once RBTools is installed you need to make sure that `rbt` is available on your

`$PATH`. To do this, you may need to add `$HOME/.local/bin` to your `$PATH`.

The exact procedure to do this is dependent on your setup and outside of the

scope of this document.

This configuration for Mercurial is to make your life as a contributor easier.

There a few different ways to configure Mercurial, but these instructions will

The first thing we need to do is to install the evolve extension. This

extension makes rewriting history safe and we use it extensively in our

[here](https://www.mercurial-scm.org/wiki/EvolveExtension).

When working with Mercurial repositories it is very important to make sure that

rebase =

```

```ini

[revsetalias]

```

This alias will show us just the commits that are on our working branch and not

contributions go. Optionally, you can add the `wip` command alias below which

will show you the revision history of what you are working on.

wip = only(.,default)

```

To be able to submit a review request you need to have an account on our

JetBrains Hub instance at [hub.imfreedom.org](https://hub.imfreedom.org). You

able to login to Review Board.

Once you have that account you can use it to login our Review Board instance at

have to login via the web interface before being able to use RBTools.

Once you have an account and have logged into our Review Board site, you can

begin using RBTools. In your shell, navigate to a Mercurial clone of one of the

Before starting a new review request, you should make sure that your

local copy of the repository is up to date. To do so, make sure you are

While it's not mandatory, it is highly recommended that you work on your

contributions via a branch. If you don't go this path, you will have

--help`. There are even options to automatically fill out the bugs fixed fields

among other things.

Typically with a code review, you're going to need to make some updates.

However there's also a good chance that your original branching point has

Rebasing, as the name suggests is the act of replaying your previous

commits on top of a new base revision. Mercurial makes this pretty easy.

After rebasing you can start addressing the comments in your review and commit

with `rbt post --update`. If for some reason `rbt` can not figure out the

Just like an initial `rbt post`, the updated version will be in a draft state

until you publish it. So again, you'll need to visit the URL that was output,

verify everything, and click the publish button.

It is ***HIGHLY*** recommended that you use a separate clone of the repository

to avoid accidentally pushing development work to the canonical repository

which makes everyone's life easier. Also, the mainline repositories now auto

publish, so if you do not selectively push commits, all of your draft commits

will be published. You can name this additional clone whatever you like, but

using something like `pidgin-clean` is a fairly common practice. This makes it

easy for you to know that this clone is only meant for landing review requests,

When you are ready to land a review request you need to make sure you are on

the proper branch. In most cases this will be the branch named ***default***

and can be verified by running the command `hg branch`. Next you need to make

Please note, if you run `hg pull` and then immediately run `hg pull --update`

you will ***not*** update to the most recent commit as this new invocation of

`hg pull` has not actually pulled in any new commits. To properly update,

you'll need to run `hg update` instead.

Once the review request has been landed, make sure to verify that the revision

history looks correct, run a test build as well as the unit tests, and if

push the new commits.

The housekeeping we need to do entails a few things. If this is a big new

Now that the changes have been made public, we can finally push to the

canonical repository with `hg push`. Once that is done, you'll also need to go

and mark the review request as ***Submitted*** in the Review Board web

interface.

If you want to test a patch locally for any reason, you first need to make sure

that you are on the target branch for the review request which is listed on the

changes that you are reverting and the `--all` argument tells Mercurial to

revert all files.

Whether or not your pull request has been accepted, you probably want to clean

it up from your local repository. To do so, you need to update to a branch

remove the branch named ***my-new-branch-name*** that we used to create a

review request.

```sh

hg up default

```

Now, all commits that were on the ***my-new-branch-name*** branch will have

You can repeat this for any other branches you need to clean up, and you're

done!