cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ariel Weisberg <>
Subject Re: Discussion: reviewing larger tickets
Date Wed, 08 Jul 2015 20:02:04 GMT

If you navigate in an IDE how do you know if you are commenting on code that has changed or

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.

> On Jul 8, 2015, at 4:00 PM, Josh McKenzie <> 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 <> 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
>> 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 <>
>> 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
>>> <
>>> (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
>> --
> -- 
> Joshua McKenzie
> DataStax -- The Apache Cassandra Company

View raw message