Is ReviewBoard a good thing?
Jesse Meek
jesse.meek at canonical.com
Sat Sep 20 06:01:15 UTC 2014
On 20/09/14 02:34, Eric Snow wrote:
> On Thu, Sep 18, 2014 at 6:19 PM, Jesse Meek <jesse.meek at canonical.com> wrote:
>> We moved to GitHub in the hope of lowering the bar to contributors outside
>> the team. GitHub is *the* platform and process for open source software.
>> This was the logic behind the move. It was deemed to have the most mindshare
>> and we sacrificed our prefered platform and process to be part of that
>> mindshare.
>>
>> We are now leaving that 'main stream' process to something that suits the
>> tastes of our team - ReviewBoard. This adds friction for new contributors
>> (friction everyone has experienced this week).
> This is mostly a consequence of moving to a new tool. Not only are we
> still getting used to a new tool, we are also learning what pain
> points it introduces. We have not had a chance yet to find reasonable
> solutions (or determine that the concerns are practically
> insurmountable). My belief is that the main concerns are solvable in
> the short term (github and reviewboard have good APIs and reviewboard
> is super extendable).
>
>> If we value our preferred
>> methods of reviewing over keeping to a well known process for outside
>> contributors, the best process was launchpad + rietveld. Shouldn't we simply
>> return to that.
> If we ditch ReviewBoard, let's just go back to GitHub. However, I
> don't think we should ditch ReviewBoard yet. It is way to early to
> make that kind of decision. Let's give it a chance and take this up
> in Brussels.
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.
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?
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. 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?
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.
>
>> Considering we have been successfully using GitHub for several months now,
>> using reviewboard is not a necessity. Obviously, I will go with whatever the
>> team decides, but I'm concerned that we have moved to reviewboard without
>> considering that it undermines (as far as I can see) our primary reason for
>> using GitHub.
> I agree that reviewboard as we currently have it now adds extra work
> to our workflow. Not only does this impact the juju team, but it does
> add a stumbling block to more community involvement. However, my firm
> belief is that the real pain points are addressable in the short term.
> Let's give it a chance.
>
> -eric
More information about the Juju-dev
mailing list