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 <[email protected]
<mailto:[email protected]>> wrote:
On Sat, Sep 20, 2014 at 12:01 AM, Jesse Meek
<[email protected] <mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
--
Juju-dev mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
