Listen for @mention of the actual bors user
Pass buildbot url as status target URL
Don't close issue if merge fails
Advance more than one PR at once

Pair programming with @Vagabond.
Create unique integration branch for each PR

Pair programming with @Vagabond.
Add .gitignore
Update .gitignore
Delete integration branches on PR-merge

Pair programming with @Vagabond.

We had to do some hackery around github retries, as the current
github.py is not very flexible. It also didn't properly handle
204 responses, as there was no content-type in the headers.
Add collaborators as reviewers option

Pair programmed with @Vagabond.

Fixes #16

When the 'collaborators_as_reviewers' = true option is added
to the config, the list of collaborators on the project will
be used instead of the hardcoded reviewer list. This allows
you to not have to keep a hardcoded list of reviewers up-to-date.
Allow configurable approval/disapproval tokens

Pair programmed with @Vagabond.

Instead of hardcoding r+, r=me, and r- for approval/disapproval
tokens, we (try to) read the list of allowed tokens from the config.
If the tokens are not overridden, we simply default to the current
implementation.
Use github's merge message for bors merges

Pair programmed with @Vagabond.

Use the same merge-commit message that github uses
for bors auto-merges. We also add a 'Reviewed-by' line
as well. This may not be interesting to upstream, but it
suits our needs.
Test and merge into target-branch

Pair programmed with @Vagabond.

Instead of always integrating with the master branch,
both for testing and merging, we honor the pull-request
target branch.
Optionally read the repository-name from cmd-line

Pair programmed with @Vagabond.

With the -r or --repo argument, you can now pass in the
respository to process. This overrides the repo config
option in the bors.cfg file. This is useful if you have a
number of repos that share the same config, save for their
repository name.

The local html and json files have not been updated to reflect
this.
Ignore edited comments for the purposes of control comments

This is necessary because comments on commits are under the control of
the fork owner, not the owner of the destination repo. This means they
can edit any comments anyone makes on one of their commits to say
whatever they want.
Allow approval comments on the PR if they are followed by a commit SHA

Pair-programmed with @reiddraper

This allows PR comments (which are not editable by the user making the
PR, in contrast to commit comments) to act as approval commends. However
because the SHA is still required, the approval is still tied to a
particular SHA so further pushes to the branch will invalidate it.
Optionally only consider $N pull-requests per run

Pair programmed with @Vagabond

If 'max_pulls_per_run' is set to a non-zero integer in the config, bors
will only consider the $N ripest pull-requests. Setting this value to
`1` will retain bors old behavior.
Use bors' github username in integration branch

Don't hardcode 'borshop' as part of the integration branch name.
Don't manually close PRs after merging

Pair programmed with @Vagabond.

We tested this and github will automatically set the status of the
pull-request to closed/merged if the HEAD of the feature branch is
contained in the target branch. This happens when we fast-forward the
target branch to the merge-sha. And specifically, it looks at the target
branch, not whatever the default branch is set to in github
(master/develop).
Implement a 'no_auto_merge' option

Pair-programmed with @reiddraper

As an option, require bors to see an "@mention merge" comment from a
collaborator before doing the final fast forward of the target branch.

Some Basho engineers are not yet comfortable with PRs being auto-merged.
This allows them to 'get their ducks in a row' before the PR is merged.
Merge pull request #21 from basho/basho-features

Basho features