From cd7751bf992b3bfab15d7a635cfb1125f8aff284 Mon Sep 17 00:00:00 2001 From: Corey Richardson Date: Sat, 7 Jun 2014 11:33:47 -0700 Subject: [PATCH] Add r=foo and p=foo --- Note-bors-usage.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/Note-bors-usage.md b/Note-bors-usage.md index 23ee8da..294c933 100644 --- a/Note-bors-usage.md +++ b/Note-bors-usage.md @@ -7,7 +7,10 @@ Its source is available [on GitHub](https://github.com/graydon/bors). Its status URL is: http://buildbot.rust-lang.org/bors/bors.html It works by scanning pull requests for r+ _on the commit_ (*not* the pull request) -from one of the reviewers. +from one of the reviewers. It also accepts the following input: + +* `r=name[,name...]` to specify that the given person(s) should be marked as the reviewer(s), rather than whoever left the comment +* `p=number` to specify the priority that the PR should be tested. Higher priority is tested first. Ties are resolved by date the PR was opened. For the most part no knowledge of bors is required of people submitting pull requests. When a reviewer signs off on one of your commits by writing "r+" @@ -47,9 +50,6 @@ also does not merge "updates" to a pull request. It considers comments on commits only, not pull requests; if you update a pull request to contain new commits, they need to be reviewed anew. -Not all commits go through it, because from time to time -we bypass it and break the tree ourselves; but we have made much use of it. - -It is somewhat slow: github has a rate-limited API so it only cycles one step every 2 +It is somewhat slow: github has a rate-limited API so it only cycles one step every 5 minutes. Which is plenty fast enough to integrate changes, but not instant-feedback fast. \ No newline at end of file