> > 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 discretion on what makes it into comments. So why don't we trust that discretion? Because discretion is usually subordinated to laziness/expediency. Only what arises out of the *necessary* portion of the process is what turns up. Review can either necessitate JIRA traffic, or it can necessitate comments. I would personally rather decisions end up documented in the code as a result of review, so they can more easily be revisited regularly, by all future authors. If the loss is that we miss a couple of miscategorized nits in the public discussion, I think that's a cost worth paying. The evidence is we are not capable of doing both. On Thu, Jul 9, 2015 at 4:09 PM, Josh McKenzie <josh.mcken...@datastax.com> wrote: > 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 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. > > On Thu, Jul 9, 2015 at 9:31 AM, Benedict Elliott Smith < > belliottsm...@datastax.com> wrote: > > > 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 discussion almost never makes its way to somewhere future authors > are > > aware of it. > > > > On Thu, Jul 9, 2015 at 2:17 PM, Robert Stupp <sn...@snazy.de> wrote: > > > > > 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 just nits (in GH)? Is it notes about concrete > > > algorithms? I don’t know. > > > > > > Something that’s really tightly integrated into JIRA so that > code-related > > > comments show up in both places (and ideally also in IDEA) might change > > my > > > opinion. > > > (Off-topic, but related: would really appreciate something that links a > > > git commit with the related ticket (basically some bot that posts the > > link > > > to that commit on github).) > > > > > > Robert > > > > > > > > > > Am 09.07.2015 um 19:57 schrieb Aleksey Yeschenko < > alek...@datastax.com > > >: > > > > > > > > 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, Benedict Elliott Smith ( > > > belliottsm...@datastax.com) wrote: > > > > > > > > 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. > > > > > > > > It also doesn't promote translating these discussions into code > > comments > > > > for the permanent record. From my POV, though, I guess I can stick to > > my > > > > current approach and just cut/paste the results into JIRA if we want > > > every > > > > nuance replicated there. > > > > > > > > On Thu, Jul 9, 2015 at 12:19 PM, Sam Tunnicliffe <s...@beobal.com> > > wrote: > > > > > > > >> 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" & "minor" > > comments, a > > > >> lot of which I would surely miss were they to move GH. I also agree > > with > > > >> the point that what seems minor to one viewer may raise red flags > with > > > >> another. > > > >> > > > >> That said, I often have offline conversations (from both the > > > >> reviewer/contributor perspective) around minor-ish things like > naming, > > > nits > > > >> and so forth. At the moment these are a) not recorded & b) > marginally > > > more > > > >> difficult to do asynchronously. So I think in future I may > personally > > > start > > > >> using a GH branch for such remarks, though I don't think that should > > > become > > > >> a mandated part of The Process. > > > >> > > > >> Sam > > > >> > > > >> On Thu, Jul 9, 2015 at 11:47 AM, Sylvain Lebresne < > > sylv...@datastax.com > > > > > > > >> wrote: > > > >> > > > >>>> 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 > much > > > more > > > >>> than > > > >>> additional convenience for making and processing review comments. > > I'll > > > >>> admit > > > >>> however that the current use of JIRA comments for reviews has never > > > >> burden > > > >>> me > > > >>> all that much so I don't see all that much convenience to be gained > > by > > > >>> changing > > > >>> that process (but then again, I'm happy using vim for my > development, > > > so > > > >>> your > > > >>> mileage probably varies). > > > >>> > > > >>> Typically, if we talk of work-flow, I personally read JIRA updates > > > fairly > > > >>> religiously, which allows me to keep vaguely up to date on what's > > going > > > >> on > > > >>> with > > > >>> reviews even for tickets I'm a priori not involved with. I consider > > it > > > a > > > >>> good, > > > >>> healthy thing. If we move some of the review material outside of > > JIRA, > > > I > > > >>> strongly suspect this won't be the case anymore due to the burden > of > > > >> having > > > >>> to > > > >>> check multiple places. > > > >>> > > > >>> Anyway, I worry a bit that changing for what I perceive as > relatively > > > >> minor > > > >>> convenience will make us lose more than we get. Just my 2 cents > > however > > > >>> really. > > > >>> > > > >>> -- > > > >>> Sylvain > > > >>> > > > >>> On Wed, Jul 8, 2015 at 11:21 PM, Michael Shuler < > > > mich...@pbandjelly.org> > > > >>> wrote: > > > >>> > > > >>>> 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 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 to start using GitHub PRs to conduct reviews, we > > > >> should > > > >>>>> follow similar contribution guidelines to what Spark has ( > > > >>>>> > > > >>>>> > > > >>> > > > >> > > > > > > https://cwiki.apache.org/confluence/display/SPARK/Contributing+to+Spark#ContributingtoSpark-PullRequest > > > >>>>> < > > > >>> > > > > https://cwiki.apache.org/confluence/display/SPARK/Contributing+to+Spark > > > >>>>>> ), > > > >>>>> and have Infra set up the same hooks for our repo. We can also > hook > > > up > > > >>>>> cassci to do the same jobs as the AmplabJenkins performs > currently. > > > >>>>> > > > >>>>> > > > >>>>> 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 > > > >>>>>> > > > >>>>>> > > > >>>>> > > > >>>> > > > >>> > > > >> > > > > > > — > > > Robert Stupp > > > @snazy > > > > > > > > > > > > -- > Joshua McKenzie > DataStax -- The Apache Cassandra Company >
