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
