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-bu...@canonical.com > <mailto: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 > <mailto: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 > <mailto: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 > <mailto: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 <mailto: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
