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-bu...@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

Reply via email to