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. On Mon, Oct 8, 2018 at 9:24 AM Antoine Pitrou <anto...@python.org> 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 <wesmck...@gmail.com> 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 <anto...@python.org> 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 <wesmck...@gmail.com> 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 <k...@clear-code.com> 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 <20181008.194105.485100005664531298....@clear-code.com> > >>>>>> "[RESULT][VOTE] Release Apache Arrow 0.11.0 (RC1)" on Mon, 08 Oct > >>>>>> 2018 > >>>>>> 19:41:05 +0900 (JST), > >>>>>> Kouhei Sutou <k...@clear-code.com> 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 > >>>>>>
