In my experience, you're best off just doing RTC for everything. Reviews are all about building up trust as a community. If a change set is "big and dumb", e.g. license header fixes, stale import removals, etc, then the review is likely to be a simple apply + build or even just an eyeball check. If your community response to one of these kinds of changes is to thoroughly evaluate them as you would a patch with substantive change, then your problem isn't that the patch was subject to RTC.
As a matter of principle, I'd object to documentation updates getting included in this kind of categorization. Docs are hard and most updates are worth a review. A recurring problem as projects scale up is making sure you don't end up with documentation issues since generally they are where new people first show up and the last place experienced devs visit. On the matter of RTC workflow, github PRs are nice when they're used (provided their comments are going to notifications@ or some such). Some projects require also attaching the patch that was used onto the jira, but so long as both the PR and the commit in the repo are linked on the jira, you probably don't need that. Much more common is to put patches onto the JIRA (and then separately upload larger ones to gerrit, reviewboard, or use the "format-like-phabricator" plugin). I'd invest at least some community time in getting used to some workflow like this, largely because I'm wary of funneling new contributors to github PRs. I think most of my hesitance is poorly-articulated intuition. One concrete issue is that PRs make it easy to miss things like enforcing properly formatted commit messages and one-jira-one-commit. They also result in git histories with lots of merges, which I personally find add unneeded overhead for those who have to deal with multiple branch lines (as well as those who have to deal with maintaining their own release+patch set). On Sun, Jan 11, 2015 at 12:34 PM, Joe Witt <[email protected]> wrote: > Apache Veterans, > > What is typical in a project trying to follow an RTC workflow? > > Benson's submission of a PR seems like an ideal way to do RTC. What > matt/mark/and I have largely done is put stuff in a branch which is often > overkill or generated a patch and appended that to a ticket. The Github PR > approach though seems like it might actually make more sense. > > Is there a 'common approach here'? > > Also, I personally have found RTC to be overkill for a non-trivial range of > changes: > - documentation updates > - license/header adjustments > - fixing maven configuration / build items > > I can see a bit of a slippery slope in the reasoning but is there merit to > defining things which are RTC vs those which are reasonable as CTR? > > Thanks > Joe > -- Sean
