I had pretty high hopes for Github Reviews but Reviews are starting to show
some rough edges.

Comments on prior commits in the PR stick around. They never go away.
Before Juju Reviews, pushing a change would hide old lines, which was bad,
because it was easy to lose track of requests and comments. Now, we have an
opposite problem -- lots of noise because comments never get hidden, they
just lose their context. We've taken to deleting some of the really
low-signal threads, which isn't great.

If we could mark these comments with an actually useful marker, like DONE,
and have them collapse... No, but we get a slice of pizza or a party hat
sticker to put on it.

-Casey

On Tue, Sep 20, 2016 at 4:54 PM, Menno Smits <menno.sm...@canonical.com>
wrote:

> (gah, hit send too early)
>
> ... If we decide to stay with RB, that will need to be fixed.
>
> On 21 September 2016 at 09:53, 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.
>>
>> 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/mailm
>>>> an/listinfo/juju-dev
>>>>
>>>
>>> --
>>> Juju-dev mailing list
>>> Juju-dev@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/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

Reply via email to