Le 08/10/2018 à 15:31, Wes McKinney a écrit :
> I personally feel pretty strongly about having a linear commit history
> with no merge commits.
> 
> Another option is that we add an option to the PR merge tool to merge
> into a branch other than master during release votes. So we can
> continue to merge PRs and then rebase those onto master later. There's
> risk that a contributor will forget to use the CLI option to merge
> into something other than master.

That sounds a bit dangerous.  I'd rather keep the current mechanism :-)



> On Mon, Oct 8, 2018 at 9:24 AM Antoine Pitrou <[email protected]> wrote:
>>
>>
>> Le 08/10/2018 à 15:21, Wes McKinney a écrit :
>>> Here's the last time we discussed this in 2017:
>>>
>>> https://lists.apache.org/thread.html/2dc068da8c5074bd7a2717475fa82abe51b323a2a8fd59529971242c@%3Cdev.arrow.apache.org%3E
>>>
>>> We have 3 choices:
>>>
>>> 1. Lock master during release votes
>>> 2. Rebase master after a release closes
>>> 3. Release from a branch, and the release commits will not be part of master
>>
>> Isn't it possible to simply merge instead of rebasing?  That way you
>> don't rewrite existing public changesets.
>>
>> Regards
>>
>> Antoine.
>>
>>
>>>
>>> So far we've been doing 2. Given the patch volume, I'm not in favor of
>>> locking down the branch for 3+ days. So we can either do 2 or 3.
>>> Option 3 will cause some of our tools (like setuptools_scm) to break
>>> On Mon, Oct 8, 2018 at 8:06 AM Wes McKinney <[email protected]> wrote:
>>>>
>>>> Our policy has been to rebase master after releases. We can discuss how we 
>>>> handle the release branch again if the community would like. In the 
>>>> meantime contributors should git reset --hard apache/master
>>>>
>>>> On Mon, Oct 8, 2018, 1:55 PM Antoine Pitrou <[email protected]> wrote:
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> Could we avoid rebasing the master branch?  I don't think it's very nice
>>>>> to force rewriting the histories of all development clones out there.
>>>>>
>>>>> "git pull" gave me a local merge commit, which I don't know what to do
>>>>> with...
>>>>>
>>>>> Regards
>>>>>
>>>>> Antoine.
>>>>>
>>>>>
>>>>>
>>>>> Le 08/10/2018 à 13:28, Kouhei Sutou a écrit :
>>>>>> Thanks!
>>>>>>
>>>>>> I've done the rebase. I'll add this task to the our Wiki.
>>>>>>
>>>>>> In <cajpuwmcdj29vnzmxaf6upipwkmqprmesrabib3suou7pgx1...@mail.gmail.com>
>>>>>>   "Re: [RESULT][VOTE] Release Apache Arrow 0.11.0 (RC1)" on Mon, 8 Oct 
>>>>>> 2018 13:06:54 +0200,
>>>>>>   Wes McKinney <[email protected]> wrote:
>>>>>>
>>>>>>> Yes, rebase the current master branch (after pulling latest) on the 
>>>>>>> release
>>>>>>> branch and force push. Thanks Kou!
>>>>>>>
>>>>>>> On Mon, Oct 8, 2018, 1:05 PM Kouhei Sutou <[email protected]> wrote:
>>>>>>>
>>>>>>>> Hi Wes,
>>>>>>>>
>>>>>>>> I have one question that isn't documented at "Post-release
>>>>>>>> tasks".
>>>>>>>>
>>>>>>>> https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-Post-releasetasks
>>>>>>>>
>>>>>>>> Should I rebase master on "release-0_1_0_rc0"
>>>>>>>> ("release-0_11_0_rc1" for this case) local branch?
>>>>>>>>
>>>>>>>>   % git fetch --all --prune
>>>>>>>>   % git checkout master
>>>>>>>>   % git rebase apache/master
>>>>>>>>   % git rebase release-0_11_0_rc1
>>>>>>>>   % git push --force apache master
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> --
>>>>>>>> kou
>>>>>>>>
>>>>>>>> In <[email protected]>
>>>>>>>>   "[RESULT][VOTE] Release Apache Arrow 0.11.0 (RC1)" on Mon, 08 Oct 
>>>>>>>> 2018
>>>>>>>> 19:41:05 +0900 (JST),
>>>>>>>>   Kouhei Sutou <[email protected]> wrote:
>>>>>>>>
>>>>>>>>> With 3 binding +1 votes, 1 non-binding +1 and no other
>>>>>>>>> votes, the vote passes. Thanks all!
>>>>>>>>>
>>>>>>>>> I'll start "Post-release tasks".
>>>>>>>>>
>>>>>>>> https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-Post-releasetasks
>>>>>>>>>
>>>>>>>>> Wes will write a blog post.
>>>>>>>>>
>>>>>>>>> Krisztián will create the conda-forge PRs.
>>>>>>>>>
>>>>>>>>> Any other helps are also welcome!
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> --
>>>>>>>>> kou
>>>>>>>>

Reply via email to