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.hard...@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@
> 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.fi...@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-bu...@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.fi...@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@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/
>> mailman/listinfo/juju-dev
>>
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju-dev
>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Reply via email to