>
> It's up to the reviewer and author to transplant summaries of those
> conversations into JIRA (or GH were we to go that route). It is also a
> very real problem that we fall short on often.
Well, that's kind of my point: you have to exercise discretion here, just
as we have to exercise discre
(It's worth noting that the reason nits get miscategorized in the first
place is exactly because we lack comments explaining necessary subtleties)
On Thu, Jul 9, 2015 at 4:21 PM, Benedict Elliott Smith <
belliottsm...@datastax.com> wrote:
> It's up to the reviewer and author to transplant summari
Thus far there seems to be a large majority for the "Put the comments in
JIRA" approach.
Benedict - your comment concerning the arbitrary nature of what makes it
into JIRA is, I think, orthogonal to the choice of tool we use for the
review process from the perspective of IRC and offline chat. It's
I should clarify that I'm not at all proposing GH, but inline comments to
be retained (perhaps in modified form) alongside the code itself.
It's already arbitrary what makes it into JIRA, and what is just assumed to
be correct, or what is discussed on IRC, or offline. But even worse is that
this d
TL;DE I’m with Sylvain, Sam and Aleksey.
Having code related comments ”nearer“ to the code would be really nice, but
OTOH having ”everything“ in once place, namely JIRA, is much more important for
me.
I mean - where’s the border about what belongs to GH comments and what must be
in JIRA? Is it
I’m with Sylvain and Sam on this, as a person drinking from the JIRA firehose.
I’m fine with review happening on GH so long as it’s also mirrored on JIRA.
Someone could write a script that would automate this (take a PR, convert it to
a JIRA-formatted comment).
—
AY
On July 9, 2015 at 15:54:48
While that approach optimises for people paying close attention to the JIRA
firehose, it is less optimal for people trying to figure out after the fact
what is going on wrt certain tickets. Some of the more complex tickets I
cannot make head or tails of even when I was one of the main participants.
I'm +1 with Sylvain here; keeping the discussions open, accessible to all
and persistent seems more valuable than reducing the friction for
contributors & reviewers.
Personally, my workflow involves following the JIRA firehose, so I tend to
be aware (at least to some degree) of both "major" & "min
> 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.
Yes, and I really worry about that. And I (see the "I", that's a totally
personal opinion) value keeping discussions as open as possible m
When we set up autojobs for the dev branches, I did some digging around
the jenkins / githubPR integration, similar to what spark is doing. I'd
be completely on board with working through that setup, if it helps this
workflow.
Michael
On 07/08/2015 03:02 PM, Carl Yeksigian wrote:
Spark has b
(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 <
belliottsm...@datastax.com> wrote:
> Except that it would lack cod
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
wrote:
> >
> > If you navigate in an IDE how do you know if y
>
> 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 I
Spark has been using the GitHub PRs successfully; they have an additional
mailing list which contains updates from GitHub (
http://mail-archives.apache.org/mod_mbox/spark-reviews/), and they also
have their PRs linked to JIRA so that going from the ticket to the PR is
easily done.
If we are going
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 wrote:
>
> The abilit
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
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 b
I've started leaning towards a hybrid approach:
I put everything I want to say, including some code changes, and sometimes
complex argumentation into comments the branch. I differentiate these into
two categories:
1. Literal comments, to remain for posterity - typically things I agree
with,
Hi,
I really like github’s workflow. If you don’t abuse it you get a history of the
entire review process.
Right now some people have a workflow that involves force pushing and deleting
branches. If you delete branches I think the pull requests are still valid so
people can still do it (althou
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
20 matches
Mail list logo
