Very good. I forgot that one can setup a git remote to several other repositories. That solves the visibility issue nicely.
________________________________ From: Steve Lawrence <[email protected]> Sent: Wednesday, October 11, 2017 12:39:40 PM To: [email protected]; Mike Beckerle Subject: Re: Infrastructure Changes for ASF On 10/11/2017 11:34 AM, Mike Beckerle wrote: > 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. > > I think github forks actually solve all three of these issues. Each person should have a personal github fork of the main Apache repo. Anytime they want to contribute a change, regardless if you're a committer or not, you do a pull request from your fork so the change can be reviewed. Using your words, the "controlled" repo is the main repo hosted by Apache that only committers have access to. The "freeforall" is each persons individual github fork. So rather than one freeforall, each person gets their own. This is more inline with the distributed model of Git. Issue 1, if you care about what a particular person is working on, then just add their fork as a git remote and fetch their branches. This is also nice in that if you only care about the progress of a few people, you can only add a few remotes and ignore everyone else. This doesn't scale easily if you want to keep track of 10s or 100s of remotes, but keeping track of that many peoples progress also doesn't really scale either, so that's not really an issue. Github will also alert you if there are conflicts with the upstream "controlled" repo, but that might only be when you do a pull request. Issue 2, since people have forks, they can push to github and get a free backup of their work. Having this in a personal instead of a freeforall repo is nice since if you're just checkpointing work it doesn't really affect anyone else--it only affects your personal repo. You can checkpoint all you want. Issue 3, if you want to review someones branch as a sort of RFC and not official review for integration, just have them push it up to their github fork, perform a pull request, and just add a comment that the PR is not to be merged but is just for an early review. Once that's done, the pull request can be closed/rejected so it won't get merged, but will still maintain the comments that came out of that review for history tracking. > > > > ________________________________ > 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. >>> >> >> >> > >
