Is ReviewBoard a good thing?

[Jesse Meek]

Thanks Nate and Eric,

Those steps look much better. The contributor will still need to log 
into review board and find their way around a new interface to respond 
to comments etc. But, let's leave this for Brussels.


On 23/09/14 04:00, Nate Finch wrote:
> So, the automation between github and reviewboard seems necessary, so 
> we should do that. It shouldn't be hard at all.  Then the steps for 
> submitting code will be:
>
> 1.) Submit a PR
> 2.) Get it reviewed on the automatically-created review.
> 3.) With a LGTM on the review, mark as $$merge$$ and the bot merges it.
> 4.) There is no step 4.
>
> Note that this is the exactly the same steps if the review is on 
> github or reviewboard.
>
> Then we can just address the pros and cons of each without worrying 
> about the impact on workflow.
>
> Github pros:
>
>   * Comfortable for people who only know github.
>   * Slightly more "visible" since the reviews happen right on github.
>
> Reviewboard pros:
>
>   * Far less email spam.
>   * Better handling of updated code mid-review.
>   * Supports chained reviews.
>   * Customizable.
>
> Let me know if I missed anything, but this still seems like 
> Reviewboard is the way to go.
>
> And yes, let's please continue to trial it until we can discuss in 
> Brussels.  We can always trivially switch back to github if/when we 
> want to.
>
>
> On Mon, Sep 22, 2014 at 11:05 AM, Eric Snow <eric.snow at canonical.com 
> <mailto:eric.snow at canonical.com>> wrote:
>
>     On Sat, Sep 20, 2014 at 12:01 AM, Jesse Meek
>     <jesse.meek at canonical.com <mailto:jesse.meek at canonical.com>> wrote:
>     > On 20/09/14 02:34, Eric Snow wrote:
>     > I was not seriously suggesting we return to lp. Using ReviewBoard
>     > reintroduces what we gave up with lp: both the good (tooling
>     that addresses
>     > pain points) and the bad (not a well known/widely adopted process of
>     > contributing). In this regard, using ReviewBoard is akin to
>     returning to lp.
>
>     Sorry, I misread.  Thanks for clarifying.
>
>     >
>     > It is not a question of "does ReviewBoard address our pain
>     points" nor is it
>     > a question of "is this just teething?". Both valid questions in
>     their own
>     > right, but they miss the point. Is raising the bar to outside
>     contributors
>     > necessary and justified?
>
>     What do you mean by raising the bar?  If you mean the extra steps
>     we've introduced for reviewboard, I agree to the extent that we do not
>     yet have any automation between github and reviewboard, and we must
>     take the steps manually.  However, once we have automated those steps
>     it will be a non-issue.
>
>     Furthermore, I will argue that reviewboard provides a better code
>     review experience than github.  That's a relatively subjective
>     assessment, but there are also concrete benefits that I hope I've
>     outlined well in the "pros and cons" thread.
>
>     FWIW, I do not plan on updating the CONTRIBUTING doc until after we
>     have github-reviewboard automation in place.  Until then outside
>     contributers won't have to worry about reviewboard.  And afterward
>     they still won't have to worry about more than simply following the
>     link to the review request for their PR.
>
>     >
>     > Is it necessary? Many of us have addressed our own pain points
>     with GitHub
>     > already. I use browser plugins, git hooks and scripts to augment my
>     > workflow.
>
>     I'd be interested to know what folks are using to work around the
>     deficiencies in github (reviews or otherwise).  I expect such things
>     would be generally useful.  Ideally no one would need to worry about
>     such workarounds, which is what we're trying to address via
>     reviewboard, but I expect that any such tools would be useful,
>     reviewboard or not.
>
>     > Yet I can work along side the first time contributor that has
>     > nothing more than git and a GitHub account. What pain point
>     necessitates
>     > raising the bar to contributors?
>
>     I agree that, without the github-reviewboard automation, any
>     requirements to use reviewboard are more roadblocks to contribution.
>
>     >
>     > Is it justified? Given such a pain point exists, does solving it
>     justify
>     > *forcing* a new tool on a developer? This is the decision we are
>     making and
>     > it is not just for 'us' the team. It is for our would-be external
>     > contributors. The ones that we moved to GitHub for.
>
>     I'm glad you spoke up on this.  It's important we keep this firmly in
>     mind when making any changes to workflow.  FYI, I had a patch for
>     CONTRIBUTING.md that updated the workflow relative to the new
>     reviewboard steps/tooling.  However, you've convinced me to abandon it
>     in favor of simply waiting until we have automation in place, to avoid
>     adding barriers to entry.  Thanks. :)
>
>     -eric
>
>     --
>     Juju-dev mailing list
>     Juju-dev at lists.ubuntu.com <mailto:Juju-dev at lists.ubuntu.com>
>     Modify settings or unsubscribe at:
>     https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140923/7b4f9cc0/attachment.html>