On Thu, Sep 15, 2016 at 6:22 AM Rick Harding <rick.hard...@canonical.com> 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 couple of weeks, and see how we feel about it then. RB isn't going to go anywhere soon - it's just a matter of whether we keep our instance alive. In case anyone's wondering about pipelines: it looks like you can review on individual commits, so that's covered. On Wed, Sep 14, 2016 at 6:13 PM Ian Booth <ian.bo...@canonical.com> wrote: > >> 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 and >> comments (ie fix this vs take note of this), plus it allows the notion of >> marking stuff as fixed vs dropped, with a reason for dropping if needed. >> So the >> github improvements are nice but there's still a large and significant >> gap that >> is yet to be filled. I for one would miss all the features reviewboard >> offers. >> Unless there's a way of doing the same thing in github that I'm not aware >> of. >> >> On 15/09/16 07:22, Tim Penhey wrote: >> > 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 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
