You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ambari.apache.org by jun aoki <ja...@apache.org> on 2016/01/26 01:27:30 UTC
how to backport? one consolidated patch vs many?
Hi Ambari committers,
We have a few jiras that have been committed to trunk but were held of
branch-2.2 as it was locked.
Now the branch is unlocked and we are ready to start backporting them.
We are thinking of a process to create a jira, and consolidate the patches
and create a single consolidated patch and attach to the jira, commit it,
rather recreate many patches for each jira.
Let us know how you guys do backporting, especially upon a previously
locked branch.
AMBARI-14656
AMBARI-14713
AMBARI-13439 <https://issues.apache.org/jira/browse/AMBARI-13439>
AMBARI-14752 <https://issues.apache.org/jira/browse/AMBARI-14752>
AMBARI-14732 <https://issues.apache.org/jira/browse/AMBARI-14732>
AMBARI-14763 <https://issues.apache.org/jira/browse/AMBARI-14763>
--
-jun
Re: how to backport? one consolidated patch vs many?
Posted by Jonathan Hurley <jh...@hortonworks.com>.
Although I typically dislike cherry-picking git commits and would rather use a merge/rebase process, it seems to work well for Ambari. The history becomes "polluted" with duplicate commit messages (each with a different hash), but this also kind of makes it easy to see exactly what was included in each branch. Since our branches are relatively short-lived, we don't hit merge conflicts too often. So, +1 on cherry-picking.
> On Jan 26, 2016, at 2:17 PM, Yusaku Sako <yu...@hortonworks.com> wrote:
>
> +1 on using existing JIRAs and doing cherry-pick to branch-2.2.
>
> Yusaku
>
>
>
>
> On 1/26/16, 10:00 AM, "Jayush Luniya" <jl...@hortonworks.com> wrote:
>
>> Generally I prefer doing "git cherry-pick" while porting fixes between
>> branches for following reasons
>>
>> - It is less error-prone as you don¹t end up missing a change that is
>> possible if you create a patch.
>> - When you see conflicts you are limited to resolving the conflict for
>> only that change.
>> - This approach will maintain revision history as the changes will be
>> committed under the same description in both branches
>> - The Apache JIRA will have comments with commits for both branches.
>>
>> Creating a single patch is best when merging a large feature that was
>> stabilized in a feature branch into the parent branch.
>>
>> Thanks
>> Jayush
>>
>> On 1/25/16, 4:27 PM, "jun aoki" <ja...@apache.org> wrote:
>>
>>> Hi Ambari committers,
>>>
>>> We have a few jiras that have been committed to trunk but were held of
>>> branch-2.2 as it was locked.
>>> Now the branch is unlocked and we are ready to start backporting them.
>>>
>>> We are thinking of a process to create a jira, and consolidate the patches
>>> and create a single consolidated patch and attach to the jira, commit it,
>>> rather recreate many patches for each jira.
>>> Let us know how you guys do backporting, especially upon a previously
>>> locked branch.
>>>
>>> AMBARI-14656
>>> AMBARI-14713
>>> AMBARI-13439 <https://issues.apache.org/jira/browse/AMBARI-13439>
>>> AMBARI-14752 <https://issues.apache.org/jira/browse/AMBARI-14752>
>>> AMBARI-14732 <https://issues.apache.org/jira/browse/AMBARI-14732>
>>> AMBARI-14763 <https://issues.apache.org/jira/browse/AMBARI-14763>
>>>
>>>
>>>
>>> --
>>> -jun
>>
>>
Re: how to backport? one consolidated patch vs many?
Posted by Yusaku Sako <yu...@hortonworks.com>.
+1 on using existing JIRAs and doing cherry-pick to branch-2.2.
Yusaku
On 1/26/16, 10:00 AM, "Jayush Luniya" <jl...@hortonworks.com> wrote:
>Generally I prefer doing "git cherry-pick" while porting fixes between
>branches for following reasons
>
>- It is less error-prone as you don¹t end up missing a change that is
>possible if you create a patch.
>- When you see conflicts you are limited to resolving the conflict for
>only that change.
>- This approach will maintain revision history as the changes will be
>committed under the same description in both branches
>- The Apache JIRA will have comments with commits for both branches.
>
>Creating a single patch is best when merging a large feature that was
>stabilized in a feature branch into the parent branch.
>
>Thanks
>Jayush
>
>On 1/25/16, 4:27 PM, "jun aoki" <ja...@apache.org> wrote:
>
>>Hi Ambari committers,
>>
>>We have a few jiras that have been committed to trunk but were held of
>>branch-2.2 as it was locked.
>>Now the branch is unlocked and we are ready to start backporting them.
>>
>>We are thinking of a process to create a jira, and consolidate the patches
>>and create a single consolidated patch and attach to the jira, commit it,
>>rather recreate many patches for each jira.
>>Let us know how you guys do backporting, especially upon a previously
>>locked branch.
>>
>>AMBARI-14656
>>AMBARI-14713
>>AMBARI-13439 <https://issues.apache.org/jira/browse/AMBARI-13439>
>>AMBARI-14752 <https://issues.apache.org/jira/browse/AMBARI-14752>
>>AMBARI-14732 <https://issues.apache.org/jira/browse/AMBARI-14732>
>>AMBARI-14763 <https://issues.apache.org/jira/browse/AMBARI-14763>
>>
>>
>>
>>--
>>-jun
>
>
Re: how to backport? one consolidated patch vs many?
Posted by Jayush Luniya <jl...@hortonworks.com>.
Generally I prefer doing "git cherry-pick" while porting fixes between
branches for following reasons
- It is less error-prone as you don¹t end up missing a change that is
possible if you create a patch.
- When you see conflicts you are limited to resolving the conflict for
only that change.
- This approach will maintain revision history as the changes will be
committed under the same description in both branches
- The Apache JIRA will have comments with commits for both branches.
Creating a single patch is best when merging a large feature that was
stabilized in a feature branch into the parent branch.
Thanks
Jayush
On 1/25/16, 4:27 PM, "jun aoki" <ja...@apache.org> wrote:
>Hi Ambari committers,
>
>We have a few jiras that have been committed to trunk but were held of
>branch-2.2 as it was locked.
>Now the branch is unlocked and we are ready to start backporting them.
>
>We are thinking of a process to create a jira, and consolidate the patches
>and create a single consolidated patch and attach to the jira, commit it,
>rather recreate many patches for each jira.
>Let us know how you guys do backporting, especially upon a previously
>locked branch.
>
>AMBARI-14656
>AMBARI-14713
>AMBARI-13439 <https://issues.apache.org/jira/browse/AMBARI-13439>
>AMBARI-14752 <https://issues.apache.org/jira/browse/AMBARI-14752>
>AMBARI-14732 <https://issues.apache.org/jira/browse/AMBARI-14732>
>AMBARI-14763 <https://issues.apache.org/jira/browse/AMBARI-14763>
>
>
>
>--
>-jun