cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedict Elliott Smith <belliottsm...@datastax.com>
Subject Re: Discussion: reviewing larger tickets
Date Wed, 08 Jul 2015 20:16:44 GMT
(git history navigation is also much more powerful in the IDE, in my
experience - can quickly scoot through many prior versions to see what the
context of prior authors was)

On Wed, Jul 8, 2015 at 9:15 PM, Benedict Elliott Smith <
belliottsmith@datastax.com> wrote:

> 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.mckenzie@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 <ariel@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.mckenzie@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 <jakers@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 <jmckenzie@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
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message