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