Reviews on Github

[Anastasia Macmood]

The A-team (:D) decided to trial reviews on github for couple of weeks
too \o/

So far, we have been very happy with the new tool.

It'd be nice to have a quick retro at the end of this trial to pool
collective experiences of the teams.

Sincerely Yours,

Anastasia


On 21/09/16 03:54, Rick Harding 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
> <mailto: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
>     <mailto: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
>     <mailto: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
>     <mailto: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 <mailto: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/20160921/99b16e63/attachment-0001.html>