4 ms·

We use ReviewBoard, which allows you to tag both a group and specific members of the team with review requests. I generally tag more than one person, and if po

We use ReviewBoard, which allows you to tag both a group and specific members of the team with review requests. I generally tag more than one person, and if possible people who know that bit of the code. I wait until I've had two signoffs (with verbal badgering if people are being slow; we are all near each other in an open plan.) I will often find myself holding out for the one person who "owns" that bit of the code before pushing the patch, though. One suggestion that we tried: People agree to do check for assigned reviews first thing, and as they return from lunch. This way people aren't interrupted from their development flow by the reviews.

bostik 11y ago
I've looked at reviewboard and so far have found two major problems with it. 1) You cannot create accounts through the API. This makes it really annoying to test and evaluate. 2) It operates primarily diffs. When you have a patch set to review, you really want to see both the overall diff, as well as the individual commits. Then, when you want to update a review with new commits to address comments on previous round, the tools do not allow to do this without manual intervention. At least I haven't found a way to run `rbtools` for review update in full noninteractive mode. Again, this acts counter to integration. From (workflow) integration point of view these two are pretty big killers. They are also the two reasons we don't yet have RB even in full-scale testing. I do want to use something that can import copies of git branches so historical reviews are available without polluting the primary gitlab installation with hundreds or thousands of stale branches.
- tehwalrus 11y ago
  We use it on a totally different toolchain: Mercurial, and MQ patches[1] (which are like temporary commits that you can reorder and change). Within that workflow it works really well; you really are editing the patch and resubmitting. I didn't have to set it up of course, it's used by everyone in a large (~100 devs) organisation. [1] https://www.mercurial-scm.org/wiki/MqExtension https://www.mercurial-scm.org/wiki/MqExtension
- chipx86 11y ago
  Hi, Review Board founder here. Let me address these real quick. 1) This has come up before. We'll probably add it. Most places that ask for it really are wanting something like an auth backend that ties into another service, like LDAP/ActiveDirectory (which are supported natively), a Single Sign-On service (which we'll be adding support for in Power Pack, our add-on product), or something more custom. For those who do want to add via the API, it's something I imagine we'll do in the next major release or two. I'll make sure it gets on the roadmap. 2) Review Board 4.0 (which is in development, alongside the upcoming 3.0) features DVCS support that will make it a lot easier to update patchsets and to keep them together as a whole without having to squash commits or create a review request per commit or anything else like that. Reviewers can view each commit individually, or the whole thing squashed, or a range squashed, and we'll help visualize how the history of those commits evolve with each update (such as adding new commits to HEAD, squashing commits together, etc.). It'll be really nice when it's done. We're also looking at adding push-to-commit through our in-development Git (and eventually Mercurial) wrapper service, rb-gateway, so that you can push a branch there and have it appear on Review Board, and keep updating that branch to update the review request. And, we're prototyping support for pull requests (first for GitHub, and then for others later), so that one can submit a pull request and have it basically appear in Review Board. This is still in the very early stages, but it's a priority. May not be relevant to your workflow, but thought I'd mention it, because that's asked a lot. Again, Review Board 4.0 is when a lot of this will make an appearance, but I'll try to get account creation via the API to happen in 3.0. (Just added it to our roadmap.)
  - axw 11y ago
    FYI, Eric Snow has implemented an OAuth extension for Review Board: https://bitbucket.org/ericsnowcurrently/rb_oauth_extension https://bitbucket.org/ericsnowcurrently/rb_oauth_extension We use this in the development of Juju. We also have a bot that creates Review Board reviews from GitHub PRs, and updates the diffs when the PR is updated.
    - chipx86 11y ago
      Sounds cool :) I'd love to hear more about your setup if you'd be up to talk about it further (christian@beanbaginc.com). Native support for OAuth2 is planned to land in 3.0 as well. We're focusing a lot on improvements for third-party integrations and enhanced extensibility with this release (along with some cool new review improvements).

bostik 11y ago

I've looked at reviewboard and so far have found two major problems with it. 1) You cannot create accounts through the API. This makes it really annoying to test and evaluate. 2) It operates primarily diffs. When you have a patch set to review, you really want to see both the overall diff, as well as the individual commits. Then, when you want to update a review with new commits to address comments on previous round, the tools do not allow to do this without manual intervention. At least I haven't found a way to run `rbtools` for review update in full noninteractive mode. Again, this acts counter to integration. From (workflow) integration point of view these two are pretty big killers. They are also the two reasons we don't yet have RB even in full-scale testing. I do want to use something that can import copies of git branches so historical reviews are available without polluting the primary gitlab installation with hundreds or thousands of stale branches.

tehwalrus 11y ago
We use it on a totally different toolchain: Mercurial, and MQ patches[1] (which are like temporary commits that you can reorder and change). Within that workflow it works really well; you really are editing the patch and resubmitting. I didn't have to set it up of course, it's used by everyone in a large (~100 devs) organisation. [1] https://www.mercurial-scm.org/wiki/MqExtension https://www.mercurial-scm.org/wiki/MqExtension
chipx86 11y ago
Hi, Review Board founder here. Let me address these real quick. 1) This has come up before. We'll probably add it. Most places that ask for it really are wanting something like an auth backend that ties into another service, like LDAP/ActiveDirectory (which are supported natively), a Single Sign-On service (which we'll be adding support for in Power Pack, our add-on product), or something more custom. For those who do want to add via the API, it's something I imagine we'll do in the next major release or two. I'll make sure it gets on the roadmap. 2) Review Board 4.0 (which is in development, alongside the upcoming 3.0) features DVCS support that will make it a lot easier to update patchsets and to keep them together as a whole without having to squash commits or create a review request per commit or anything else like that. Reviewers can view each commit individually, or the whole thing squashed, or a range squashed, and we'll help visualize how the history of those commits evolve with each update (such as adding new commits to HEAD, squashing commits together, etc.). It'll be really nice when it's done. We're also looking at adding push-to-commit through our in-development Git (and eventually Mercurial) wrapper service, rb-gateway, so that you can push a branch there and have it appear on Review Board, and keep updating that branch to update the review request. And, we're prototyping support for pull requests (first for GitHub, and then for others later), so that one can submit a pull request and have it basically appear in Review Board. This is still in the very early stages, but it's a priority. May not be relevant to your workflow, but thought I'd mention it, because that's asked a lot. Again, Review Board 4.0 is when a lot of this will make an appearance, but I'll try to get account creation via the API to happen in 3.0. (Just added it to our roadmap.)
- axw 11y ago
  FYI, Eric Snow has implemented an OAuth extension for Review Board: https://bitbucket.org/ericsnowcurrently/rb_oauth_extension https://bitbucket.org/ericsnowcurrently/rb_oauth_extension We use this in the development of Juju. We also have a bot that creates Review Board reviews from GitHub PRs, and updates the diffs when the PR is updated.
  - chipx86 11y ago
    Sounds cool :) I'd love to hear more about your setup if you'd be up to talk about it further (christian@beanbaginc.com). Native support for OAuth2 is planned to land in 3.0 as well. We're focusing a lot on improvements for third-party integrations and enhanced extensibility with this release (along with some cool new review improvements).