> > 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
