Two things I've noticed today while doing OCR duties are: 1. There's no way to tell if a PR has a review when looking at the list of open PRs. I may be missing something or it may be an oversight on the part of GH and will likely be remedied soon. When there are comments it shows little comment clouds and a count, but not if there's only a review nothing shows there for me. 2. When someone amends a commit and force pushes, the review remains but isn't attached to a commit any longer. You can see that there was an update because the commit appears later in the timeline than the review on the PR details view. Personally, I think that once you make a PR and involve someone else we shouldn't rewrite history anymore.
On Wed, Sep 21, 2016 at 4:37 AM, Andrew Wilkins < andrew.wilk...@canonical.com> wrote: > On Wed, Sep 21, 2016 at 5:53 AM Menno Smits <menno.sm...@canonical.com> > wrote: > >> 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. >> > > 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. > > There are pros and cons to each; neither is perfect. You can find the main > points of discussion in the tech board agenda. > > Please give it a shot and provide your criticisms so we decide on the best > path forward at the end of the trial. > > Cheers, > Andrew > > 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-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 >>> >>> >> -- >> 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 > > -- Reed O'Brien ✉ reed.obr...@canonical.com ✆ 415-562-6797
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
