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