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