Review branches have a lot of value.
1) Work Visibility I like being able to see OTHER developers review branches as a means of avoiding duplicate work, seeing if they are progressing, or the branches go quiet, are their changes going to create an integration nightmare with mine, or my planned changes. So we lose a lot by not having review branches. I would suggest maybe one needs two repos. Let's call one "controlled", and the other "freeforall". The controlled one, only selected people can integrate into. The freeforall any project developer can create their own review branches on, and which is frequently updated from changes on the controlled one. This is an approximation of a git feature that doesn't exist which is per-branch access controls. 2) Backups One issue with the pull-request system where no review branches are created,.... is that a developer does not automatically get a place to checkpoint/backup their work to a repo. My development machine does automatic incremental backups but I believe this is not standard practice among developers who know and love git. Many developers rely on being able to push their own branches at will as a means of checkpointing their work. In a patch-driven no-review-branches workflow, one needs a separate remote git repo for this. There are ways to address this - e.g., an organization (such as Tresys) can have it's own clone of the apache repo, and developers can have all the branches they want on that. But let's say there's an individual contributor. They'd have to setup say, their own fork repo on github to have a place to push to where they are unconstrained. This is perhaps just fine for backups, but visibility... every developer having their own backup repo makes cross-team visibility harder. 3) Code-Review with no Integration Intent I also want to be sure I understand how I engage code-review by others with no intention whatsoever of integrating into the master. I.e., I just want to get some other people's eyes on some code in its formative stages (early reviews have more leverage than "just before integration" reviews), and I want to do this using the exact same code-review tool chain that is used for other kinds of pre-integration reviews. ________________________________ From: Steve Lawrence <[email protected]> Sent: Wednesday, October 11, 2017 10:38:12 AM To: [email protected]; Taylor Wise Cc: [email protected] Subject: Re: Infrastructure Changes for ASF On 10/11/2017 10:17 AM, Taylor Wise wrote: > I see your point. In these cases would it make more sense then to link it > to the PR when closing the ticket? As in add a comment with a direct link > to the PR to more easily view the comments? Perhaps. Looking at Apache Spark, it looks like they do not have PR comments in JIRA comments, for example: PR: https://github.com/apache/spark/pull/19466 JIRA: https://issues.apache.org/jira/browse/SPARK-22237 Some more digging found this INFRA issue: https://issues.apache.org/jira/browse/INFRA-11675 Which was fixed to make the ASF Github Bot add PR comments to the worklog rather than the comments. I'm not sure if NiFi just never updated some config, or if they chose that, but it seems like PR comments in JIRA comments is optional somehow. > On Wed, Oct 11, 2017 at 10:04 AM, Steve Lawrence <[email protected]> > wrote: > >> On 10/11/2017 09:36 AM, Taylor Wise wrote: >>> On Wed, Oct 11, 2017 at 8:39 AM, Steve Lawrence <[email protected]> >>> wrote: >>> >>>> >>>> A similar method would be to use github. Apache mirrors the Daffodil git >>>> repository to github, and with the use of Apache gitbox, can even >>>> support accepting github pull requests. This has some very obvious >>>> benefits. Many people are already very familiar with github and so could >>>> be a good way to attract more contributors. It also has an intuitive >>>> interface for creating and accepting pull requests, again reducing >>>> barrier to entry. Github also very cleanly integrates with TravisCI to >>>> test pull requests. Note that JIRA must still be the bug tracker, and >>>> gitbox copies all review comments to the original JIRA bug as comments. >>>> This is good for tracking the review comments, but makes JIRA bugs >>>> pretty messy and hard to follow. Also, there are some criticism of the >>>> github code review interface, or people that simple do not want or have >>>> a github account. Like the above, it also requires network connectivity >>>> to draft reviews, though this may be a non-issue nowadays. >>>> >>> >>> I personally like the interface provided by GitHub. At least with the >>> graphical diff it makes it easy to see the immediate changes as well as >>> historically what has changed. How does it make the JIRA bugs messy? >> I'm >>> curious, I haven't seen this in action. >>> >> >> Yeah, the github interface is definitely much prettier and somewhat >> easier to look at than ReviewBoard or email diffs (though, I'm used to >> email diffs on other projects, so it's all the same to me). And the >> TravisCI integration is very appealing to me. Though, I would kindof >> miss the ability to have nested review comments. >> >> As an example of the JIRA messiness, Apache NiFi uses the github >> workflow. Here is a random pull request with 11 comments on one commit: >> >> https://github.com/apache/nifi/pull/2162 >> >> And here is the associated JIRA issue with those comments copied in: >> >> https://issues.apache.org/jira/browse/NIFI-1706 >> >> Here's another one that's particularly bad with huge diffs in the JIRA >> comments: >> >> PR: https://github.com/apache/nifi/pull/2181 >> JIRA: https://issues.apache.org/jira/browse/NIFI-4428 >> >> Neither of these pull requests are particularly complicated too. Imagine >> this with some of the big patches we've had in the past with lots of >> comments. >> >> It's not terrible, but I think it makes legitimate JIRA comments >> difficult to find, and might even discourage comments in JIRA issues--I >> haven't looked alot, but I have yet to find anything other than ASF >> Github Bot comments in the NiFi JIRA issues. >> > > >
