Reviews on Github

[Nate Finch]

Personally, I really enjoy having everything in the same place, more than I
expected. It's also one less barrier of entry for newcomers and outsiders.

On Tue, Sep 20, 2016, 5:54 PM Menno Smits <menno.smits at canonical.com> wrote:

> (gah, hit send too early)
>
> ... If we decide to stay with RB, that will need to be fixed.
>
> On 21 September 2016 at 09:53, Menno Smits <menno.smits at canonical.com>
> wrote:
>
>> Some of us probably got a little excited (me included). There should be
>> discussion and a clear announcement before we make a signigicant change to
>> our process. The tech board meeting is today/tonight so we'll discuss it
>> there as per Rick's email. Please contribute to this thread if you haven't
>> already and have strong opinions either way on the topic.
>>
>> Interestingly our Github/RB integration seems to have broken a little
>> since Github made these changes. The links to Reviewboard on pull requests
>> aren't getting inserted any more. If we decide to stay with RB
>>
>> On 21 September 2016 at 05:54, Rick Harding <rick.harding at canonical.com>
>> wrote:
>>
>>> I spoke with Alexis today about this and it's on her list to check with
>>> her folks on this. The tech board has been tasked with he decision, so
>>> please feel free to shoot a copy of your opinions their way. As you say, on
>>> the one hand it's a big impact on the team, but it's also a standard
>>> developer practice that not everyone will agree with so I'm sure the tech
>>> board is a good solution to limiting the amount of bike-shedding and to
>>> have some multi-mind consensus.
>>>
>>> On Tue, Sep 20, 2016 at 1:52 PM Katherine Cox-Buday <
>>> katherine.cox-buday at canonical.com> wrote:
>>>
>>>> Seems like a good thing to do would be to ensure the tech board doesn't
>>>> have any objections and then put it to a vote since it's more a property of
>>>> the team and not the codebase.
>>>>
>>>> I just want some consistency until a decision is made. E.g. "we will be
>>>> trying out GitHub reviews for the next two weeks; all reviews should be
>>>> done on there".
>>>>
>>>> --
>>>> Katherine
>>>>
>>>> Nate Finch <nate.finch at canonical.com> writes:
>>>>
>>>> > Can we try reviews on github for a couple weeks? Seems like we'll
>>>> > never know if it's sufficient if we don't try it. And there's no setup
>>>> > cost, which is nice.
>>>> >
>>>> > On Tue, Sep 20, 2016 at 12:44 PM Katherine Cox-Buday
>>>> > <katherine.cox-buday at canonical.com> wrote:
>>>> >
>>>> >     I see quite a few PRs that are being reviewed in GitHub and not
>>>> >     ReviewBoard. I really don't care where we do them, but can we
>>>> >     please pick a direction and move forward? And until then, can we
>>>> >     stick to our previous decision and use RB? With people using both
>>>> >     it's much more difficult to tell what's been reviewed and what
>>>> >     hasn't.
>>>> >
>>>> >     --
>>>> >     Katherine
>>>> >
>>>> >     Nate Finch <nate.finch at canonical.com> writes:
>>>> >
>>>> >     > In case you missed it, Github rolled out a new review process.
>>>> >     It
>>>> >     > basically works just like reviewboard does, where you start a
>>>> >     review,
>>>> >     > batch up comments, then post the review as a whole, so you don't
>>>> >     just
>>>> >     > write a bunch of disconnected comments (and get one email per
>>>> >     review,
>>>> >     > not per comment). The only features reviewboard has is the edge
>>>> >     case
>>>> >     > stuff that we rarely use: like using rbt to post a review from a
>>>> >     > random diff that is not connected directly to a github PR. I
>>>> >     think
>>>> >     > that is easy enough to give up in order to get the benefit of
>>>> >     not
>>>> >     > needing an entirely separate system to handle reviews.
>>>> >     >
>>>> >     > I made a little test review on one PR here, and the UX was
>>>> >     almost
>>>> >     > exactly like working in reviewboard:
>>>> >     > https://github.com/juju/juju/pull/6234
>>>> >     >
>>>> >     > There may be important edge cases I'm missing, but I think it's
>>>> >     worth
>>>> >     > looking into.
>>>> >     >
>>>> >     > -Nate
>>>>
>>>> --
>>>> Juju-dev mailing list
>>>> Juju-dev at lists.ubuntu.com
>>>> Modify settings or unsubscribe at:
>>>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>>>
>>>
>>> --
>>> Juju-dev mailing list
>>> 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/20160920/d6607ccb/attachment-0001.html>