RTC : Ease of process

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

RTC : Ease of process

Joe Witt
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
Reply | Threaded
Open this post in threaded view
|

Re: RTC : Ease of process

Benson Margulies
On Sun, Jan 11, 2015 at 1:34 PM, Joe Witt <[hidden email]> 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'?
>

At Lucene, here is the PR workflow:

Workflow 1: a committer submits a PR.

  a: committer attaches PR to JIRA
  b: community fails to complain for a few days
  c: committer merges to develop, including the magic incantation in the
merge commit that causes the infrastructure to close the PR.

Workflow 2: a non-committer submits a PR

  a: noncommitter attaches PR to JIRA
  b: community fails to complain
  c:  committer merges to develop, including the magic incantation in the
merge commit that causes the infrastructure to close the PR.

No extra branches, no muss, no fuss. In both cases, committer has git repo
with (at least) two remotes: the real Apache repo and the repo that the PR
was launched from.






>
> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: RTC : Ease of process

Sean Busbey
In reply to this post by Joe Witt
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: RTC : Ease of process

Benson Margulies
On Tue, Jan 13, 2015 at 5:33 PM, Sean Busbey <[hidden email]> 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 <[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: RTC : Ease of process

Joey Echeverria
> 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.

When JIRA and commit are not 1-1, it's very hard to answer the question:

Is this JIRA fixed in this release/branch/distribution/whatever?

This is exacerbated when development is done directly in the main
development branch (be that master or develop) as you'll get commits
for multiple JIRAs interleaved. You can avoid this with the current
gitflow style development where all of the work happens in a branch
and then is merged in, but then you have the problem of merge commits
that Sean pointed out.

In general, just because the process of developing a fix is multiple
commits doesn't mean that is the best way to capture history in the
project itself. The project should be more interested in the history
of issues fixed rather than how those fixes were developed.

WRT github PRs, I've found that you can have workflow based on them
that works well without extra merge commits. The trick is to not use
the "Merge pull request" button. I personally use the workflow
described here:

http://blog.spreedly.com/2014/06/24/merge-pull-request-considered-harmful/#.VLWnbcaPmho

The TLDR; version is:

# Update my working copy to the latest development branch
git fetch origin
git rebase origin/develop

# Apply the PR as a patch
git am -3 <github PR url>

# Rebase to make sure the commit is relative to the current branch and
to squash multiple commits into one.
git rebase -i origin/develop

This also gives me an opportunity to do one final review before I push
the change in case I missed something.

-Joey

On Tue, Jan 13, 2015 at 3:06 PM, Benson Margulies <[hidden email]> wrote:

> On Tue, Jan 13, 2015 at 5:33 PM, Sean Busbey <[hidden email]> 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 <[hidden email]> 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
>>



--
Joey Echeverria