4 ms·

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 te

by 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).
    - chipx86 11y ago
      Oh I should be clear (misunderstood that extension). We're adding support for using Review Board as an OAuth2 provider, not to use another service for auth, so that services can better integrate into your server without having to share credentials.
- bostik 11y ago
  Oh hi, this was an unexpected pleasure. My usecase for item 1 is a bit special, I can admit. The pain point came up when I tried to set up RB for testing, and interestingly enough both items tie directly into each other. - Reviews need to be generated automatically when suitable trigger conditions are met. This means that there has to be a dedicated user account in RB that can create reviews on behalf of other users. Reviews also need to be automatically updated when new changes land in the branch under review. - While setting RB up, it's not at all uncommon to do a round of install/provision/repopulate iterations. Without the ability to generate users and assign their permissions through an API the automation and iteration go out of the window. - The account permissions for RB are very granular. I don't want to manage these permissions via a web-UI, I want them populated and updated based on reviewable commits. Hence, everything must go through config management. Yet another web-UI for managing yet another set of accounts and permissions is ... increasingly repulsive. I can understand where the permission and account creation friction comes from. For you, RB is a product. (Hell, it certainly is one!) For me, RB is simply a tool, and as such it has to integrate with other tools. Code review tool is an extremely important one, but without fluid integration with other development workflow tools it becomes an additional burden to maintain. For developers who don't need to worry about integration efforts, yet another extra account adds to the cognitive overhead. Furthermore, I realise your permission model is tightly coupled with the underlying architecture, which itself builds on top of Django. Exposing the kind of functionality I ask for requires to expose and nest quite a few internal API layers. I do genuinely see why that has not been roadmap item so far. Codewise that is a big undertaking. As for item number 2... you just made me drool. I haven't seen a tool yet that would allow to easily see change comparisons with dynamic interdiff windows. Having visibility into how a change set has evolved, and what the compound intermediate results have been between any given steps would be a huge boon. (No, `git diff ref1..ref2` is not ideal. On the other hand something like `git show ref1 ref2 ref3..ref6 ref7..ref8` gets a lot closer.) Once you have native DVCS support and push-to-commit for fluid integration between other tools, RB has the ability become "just another tool". I see that as a good thing :) I haven't yet tried phabricator (evaluating it is on our infrastructure team's roadmap), but so far it looks like it tries to do too much. You guessed correctly, the PR integration is not relevant for me, but I can definitely see how it would better integrate with lots of teams' workflows. No wonder it gets asked for. > 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.) Thank you. Thank you so much. NB. I am a big believer in tooling and workflow. Related to that, I have developed an increasing intolerance to anything that cannot be configured via config management. Changes to infrastructure are no different to changes in code - everything needs to be reviewable and versioned. (Which also means that the infrastructure must be rebuildable with minimal manual steps.)

by bostik 11y ago

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).
  - chipx86 11y ago
    Oh I should be clear (misunderstood that extension). We're adding support for using Review Board as an OAuth2 provider, not to use another service for auth, so that services can better integrate into your server without having to share credentials.
bostik 11y ago
Oh hi, this was an unexpected pleasure. My usecase for item 1 is a bit special, I can admit. The pain point came up when I tried to set up RB for testing, and interestingly enough both items tie directly into each other. - Reviews need to be generated automatically when suitable trigger conditions are met. This means that there has to be a dedicated user account in RB that can create reviews on behalf of other users. Reviews also need to be automatically updated when new changes land in the branch under review. - While setting RB up, it's not at all uncommon to do a round of install/provision/repopulate iterations. Without the ability to generate users and assign their permissions through an API the automation and iteration go out of the window. - The account permissions for RB are very granular. I don't want to manage these permissions via a web-UI, I want them populated and updated based on reviewable commits. Hence, everything must go through config management. Yet another web-UI for managing yet another set of accounts and permissions is ... increasingly repulsive. I can understand where the permission and account creation friction comes from. For you, RB is a product. (Hell, it certainly is one!) For me, RB is simply a tool, and as such it has to integrate with other tools. Code review tool is an extremely important one, but without fluid integration with other development workflow tools it becomes an additional burden to maintain. For developers who don't need to worry about integration efforts, yet another extra account adds to the cognitive overhead. Furthermore, I realise your permission model is tightly coupled with the underlying architecture, which itself builds on top of Django. Exposing the kind of functionality I ask for requires to expose and nest quite a few internal API layers. I do genuinely see why that has not been roadmap item so far. Codewise that is a big undertaking. As for item number 2... you just made me drool. I haven't seen a tool yet that would allow to easily see change comparisons with dynamic interdiff windows. Having visibility into how a change set has evolved, and what the compound intermediate results have been between any given steps would be a huge boon. (No, `git diff ref1..ref2` is not ideal. On the other hand something like `git show ref1 ref2 ref3..ref6 ref7..ref8` gets a lot closer.) Once you have native DVCS support and push-to-commit for fluid integration between other tools, RB has the ability become "just another tool". I see that as a good thing :) I haven't yet tried phabricator (evaluating it is on our infrastructure team's roadmap), but so far it looks like it tries to do too much. You guessed correctly, the PR integration is not relevant for me, but I can definitely see how it would better integrate with lots of teams' workflows. No wonder it gets asked for. > 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.) Thank you. Thank you so much. NB. I am a big believer in tooling and workflow. Related to that, I have developed an increasing intolerance to anything that cannot be configured via config management. Changes to infrastructure are no different to changes in code - everything needs to be reviewable and versioned. (Which also means that the infrastructure must be rebuildable with minimal manual steps.)