Re: Reviews on Github

ere as per Rick's email. Please contribute to this thread if you haven't >>> already and have strong opinions either way on the topic. >>> >> >> We discussed Github reviews vs. Reviewboard at the tech board meeting >> today, and we all agreed that we should go ahead

Re: Reviews on Github

mail. Please contribute to this thread if you haven't >> already and have strong opinions either way on the topic. >> > > We discussed Github reviews vs. Reviewboard at the tech board meeting > today, and we all agreed that we should go ahead with a trial for 2 weeks. > > Th

Re: Reviews on Github

onight 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. > We discussed Github reviews vs. Reviewboard at the tech board meeting today, and we all agreed that we should go ahead

Re: Reviews on Github

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

Re: Reviews on Github

; 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. >>> &

Re: Reviews on Github

ing 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

Re: Reviews on Github

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 nex

Re: Reviews on Github

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

Re: Reviews on Github

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

Re: Reviews on Github

On 16/09/16 03:50, Nate Finch wrote: > Reviewboard goes down a couple times a month, usually from lack of disk > space or some other BS. According to a source knowledgeable with these > matters, the charm was rushed out, and the agent for that machine is down > anyway, so we're kinda just

Re: Reviews on Github

On 16/09/16 08:54, Anastasia Macmood wrote: > On 16/09/16 08:02, Ian Booth wrote: >> Another data point - in the past, when we have had PRs which touch a lot of >> files (eg change the import path for a dependency), review board paginates >> the >> diff so it's much easier to manage, whereas

Re: Reviews on Github

On 16/09/16 08:02, Ian Booth wrote: > Another data point - in the past, when we have had PRs which touch a lot of > files (eg change the import path for a dependency), review board paginates the > diff so it's much easier to manage, whereas I've seen github actually truncate > what it displays

Re: Reviews on Github

Another data point - in the past, when we have had PRs which touch a lot of files (eg change the import path for a dependency), review board paginates the diff so it's much easier to manage, whereas I've seen github actually truncate what it displays because the diff is "too large". Hopefully this

Re: Reviews on Github

Although I share some of Ian's concerns, I think the reduced moving parts, improved reliability, reduced maintenance, easier experience for outside contributors and better handling of file moves are pretty big wins. The rendering of diffs on Github is a whole lot nicer as well. I'm +1 for

Re: Reviews on Github

Reviewboard goes down a couple times a month, usually from lack of disk space or some other BS. According to a source knowledgeable with these matters, the charm was rushed out, and the agent for that machine is down anyway, so we're kinda just waiting for the other shoe to drop. As for the

Re: Reviews on Github

On Thu, Sep 15, 2016 at 6:22 AM Rick Harding wrote: > I think that the issue is that someone has to maintain the RB and the > cost/time spent on that does not seem commensurate with the bonus features > in my experience. > Agreed and +1. I propose we all try it for a

Re: Reviews on Github

+1 on moving away from RB \o/ Currently contributors need to allow RB to run against their github fork, if they don't then we do not see their contributions on RB and PRs go un-reviewed and seem ignored. Communication between github and RB is not optimal: we had plenty of instances where RB

Re: Reviews on Github

I think that the issue is that someone has to maintain the RB and the cost/time spent on that does not seem commensurate with the bonus features in my experience. On Wed, Sep 14, 2016 at 6:13 PM Ian Booth wrote: > One thing review board does better is use gutter

Re: Reviews on Github

One thing review board does better is use gutter indicators so as not to interrupt the flow of reading the code with huge comment blocks. It also seems much better at allowing previous commits with comments to be viewed in their entirety. And it allows the reviewer to differentiate between issues

Re: Reviews on Github

I'm +1 if we can remove the extra tools and we don't get email per comment. On 15/09/16 08:03, Nate Finch wrote: 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

Re: Reviews on Github

As long as we can have draft reviews like on RB and not email-spam-per-comment, totally +1 On 09/14/2016 01:25 PM, Horacio Duran wrote: > Also +1 for that source not being review board > > On Wed, Sep 14, 2016 at 5:23 PM, Reed O'Brien

Re: Reviews on Github

I'm halfway through my first Github review (different project though) on the new system, and so far I'm loving it. Also consider the issues we've had with rbt being unable to handle diffs with files added/removed/relocated. +1 from me! -Casey On Wed, Sep 14, 2016 at 3:23 PM, Reed O'Brien

Re: Reviews on Github

Also +1 for that source not being review board On Wed, Sep 14, 2016 at 5:23 PM, Reed O'Brien wrote: > Also +1 for a single source of truth. > > On Wed, Sep 14, 2016 at 1:20 PM, Rick Harding > wrote: > >> /me is always +1 on reducing the

Re: Reviews on Github

/me is always +1 on reducing the number of things we have to maintain and keeping things simpler. On Wed, Sep 14, 2016 at 4:04 PM Nate Finch wrote: > In case you missed it, Github rolled out a new review process. It > basically works just like reviewboard does, where

Reviews on Github

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).