Except that it would lack code navigation. So it would be alt-tabbing, then clicking through the clunky interface to find the file I want, and the location, which can be very cumbersome.
On Wed, Jul 8, 2015 at 9:13 PM, Josh McKenzie <josh.mcken...@datastax.com> wrote: > > > > If you navigate in an IDE how do you know if you are commenting on code > > that has changed or not? > > I end up in the diff view and alt-tabbing over to the code view to look for > details to navigate. In retrospect, working with a github diff would just > be tabbing between a browser and IDE vs. an IDE diff and the IDE. > > On Wed, Jul 8, 2015 at 4:02 PM, Ariel Weisberg <ar...@weisberg.ws> wrote: > > > Hi, > > > > If you navigate in an IDE how do you know if you are commenting on code > > that has changed or not? > > > > My workflow is usually to look at the diff and have it open in an IDE > > separately, but maybe I am failing hard at tools. > > > > Ariel > > > On Jul 8, 2015, at 4:00 PM, Josh McKenzie <josh.mcken...@datastax.com> > > wrote: > > > > > > The ability to navigate a patch in an IDE and add comments while > > exploring > > > is not something the github PR interface can provide; I expect I at > least > > > would end up having to use multiple tools to perform a review given the > > PR > > > approach. > > > > > > On Wed, Jul 8, 2015 at 3:50 PM, Jake Luciani <jak...@gmail.com> wrote: > > > > > >> putting comments inline on a branch for the initial author to inspect > > >> > > >> I agree and I think we can support this by using github pull requests > > for > > >> review. > > >> > > >> Pull requests live forever even if the source branch is removed. See > > >> https://github.com/apache/cassandra/pull/4 > > >> They also allow for comments to be updated over time as new fixes are > > >> pushed to the branch. > > >> > > >> Once review is done we can just close them without committing and just > > >> commit the usual way > > >> > > >> Linking to the PR in JIRA for reference. > > >> > > >> > > >> On Wed, Jul 8, 2015 at 3:21 PM, Josh McKenzie <jmcken...@apache.org> > > >> wrote: > > >> > > >>> As some of you might have noticed, Tyler and I tossed around a couple > > of > > >>> thoughts yesterday regarding the best way to perform larger reviews > on > > >>> JIRA. > > >>> > > >>> I've been leaning towards the approach Benedict's been taking lately > > >>> w/putting comments inline on a branch for the initial author to > inspect > > >> as > > >>> that provides immediate locality for a reviewer to write down their > > >>> thoughts and the same for the initial developer to ingest them. One > > >>> downside to that approach is that the extra barrier to entry makes it > > >> more > > >>> of a 1-on-1 conversation rather than an open discussion via JIRA > > >> comments. > > >>> Also, if one deletes branches from github we then lose our discussion > > >>> history on the review process which is a big problem for digging into > > why > > >>> certain decisions were made or revised during the process. > > >>> > > >>> On the competing side, monster comments like this > > >>> < > > >>> > > >> > > > https://issues.apache.org/jira/browse/CASSANDRA-6477?focusedCommentId=14617221&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14617221 > > >>>> > > >>> (which > > >>> is one of multiple to come) are burdensome to create and map into a > > JIRA > > >>> comment and, in my experience, also a burden to map back into the > > >> code-base > > >>> as a developer. Details are lost in translation; I'm comfortable > > labeling > > >>> this a sub-optimal method of communication. > > >>> > > >>> So what to do? > > >>> > > >>> -- > > >>> Joshua McKenzie > > >>> > > >> > > >> > > >> > > >> -- > > >> http://twitter.com/tjake > > >> > > > > > > > > > > > > -- > > > Joshua McKenzie > > > DataStax -- The Apache Cassandra Company > > > > > > > -- > Joshua McKenzie > DataStax -- The Apache Cassandra Company >
