<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Thanks Nate and Eric,<br>
<br>
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.<br>
<br>
<div class="moz-cite-prefix"><br>
On 23/09/14 04:00, Nate Finch wrote:<br>
</div>
<blockquote
cite="mid:CAK=yn+v8AwCzY9nyeE0fcz=UTfqD9tgtJN5swjbhpJRHoUZwYA@mail.gmail.com"
type="cite">
<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>
</blockquote>
<blockquote
cite="mid:CAK=yn+v8AwCzY9nyeE0fcz=UTfqD9tgtJN5swjbhpJRHoUZwYA@mail.gmail.com"
type="cite">
<div class="gmail_extra">
<div class="gmail_quote">On Mon, Sep 22, 2014 at 11:05 AM, Eric
Snow <span dir="ltr"><<a moz-do-not-send="true"
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
moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a
moz-do-not-send="true"
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>
</blockquote>
<br>
</body>
</html>