+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 would close a review but github PR is still active; as well as the other way around. RB is also not configured on some of our "external" libraries under github/juju. So we are not reviewing these proposals either... Not to mention that we still need to fall back to github to confirm that there are no conflicts on PRs as RB does not report that. On 15/09/16 08:22, 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. > > On Wed, Sep 14, 2016 at 6:13 PM Ian Booth <ian.bo...@canonical.com > <mailto: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 <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
