On Tue, Jan 13, 2015 at 5:33 PM, Sean Busbey <[email protected]> wrote:
> 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. > Why do you want to make JIRA and commit 1-1? Not that I matter, but I really hate compulsive repacking. If the natural development of a task is several commits, it's several commits. > > 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 >
