I am sorry that I merged a commit while the release is going on too. I see Julain suggests the release manager(Danny) rebase master.
Danny, please feel free to tell me if I can do some help. Thank you for your effort~~ Best, Chunwei On Fri, Feb 28, 2020 at 6:17 AM Julian Hyde <[email protected]> wrote: > While you rebase you can also squash the two commits you made for > CALCITE-3825 into one. > > > On Feb 27, 2020, at 1:55 PM, Jesus Camacho Rodriguez < > [email protected]> wrote: > > > > Makes sense; I will modify the commit messages in those JIRAs accordingly > > once they are pushed again. > > > > -Jesús > > > > On Thu, Feb 27, 2020 at 1:38 PM Julian Hyde <[email protected]> wrote: > > > >> I think the best course is that the release manager (Danny) rebases > master > >> after the RC has been accepted, just before he re-openes the master > branch. > >> The SHAs of your commits will change, but this is unavoidable. > >> > >>> On Feb 27, 2020, at 10:58 AM, Jesus Camacho Rodriguez > >> <[email protected]> wrote: > >>> > >>> I had not been very active for some time and I did not see this message > >> in > >>> the mailing list. > >>> > >>> I am responsible for pushing some of those commits while the release is > >>> going on; I am sorry about that. Iirc we could force commit on master? > I > >>> can fix it if you think it's the right thing to do. > >>> > >>> Thanks, > >>> Jesús > >>> > >>> On Wed, Feb 26, 2020 at 10:50 AM Michael Mior <[email protected]> > wrote: > >>> > >>>> I don't believe we have ever articulated an "official" policy on this. > >>>> But yes, it's generally expected that once the process of preparing a > >>>> release has started, no one will commit to master without checking > >>>> with the release manager. It's up to this person to judge whether a > >>>> commit is important/safe enough to include into the release. I haven't > >>>> checked who authored these commits, but I'm going to assume the > >>>> possibility they were not aware of a release in progress. This is a > >>>> good reminder to all committers to keep aware of the release cycle. > >>>> -- > >>>> Michael Mior > >>>> [email protected] > >>>> > >>>> Le mer. 26 févr. 2020 à 09:33, Stamatis Zampetakis <[email protected] > > > >> a > >>>> écrit : > >>>>> > >>>>> Hello, > >>>>> > >>>>> As far as I remember [1, 2, 3] the commits on master are suspended > >> during > >>>>> the release process. > >>>>> In principle, if there is a commit that should go in it should pass > by > >>>> the > >>>>> release manager and its up to him to decide if he wants to include it > >> or > >>>>> not. > >>>>> Now if I am missing something I leave the more senior members fill in > >> the > >>>>> details. > >>>>> > >>>>> Best, > >>>>> Stamatis > >>>>> > >>>>> [1] > >>>>> > >>>> > >> > https://lists.apache.org/thread.html/5cfea82c9e14d921e80ab3beb35d508996d18de1d45dd61404b21ca1%40%3Cdev.calcite.apache.org%3E > >>>>> [2] > >>>>> > >>>> > >> > https://lists.apache.org/thread.html/1d2d226d501154aa909364c0f954da7f41e401e92013129d772d041c%40%3Cdev.calcite.apache.org%3E > >>>>> [3] > >>>>> > >>>> > >> > https://lists.apache.org/thread.html/4402577cc2a596e0b221bbde53cac9f0d88568373d337f435199eb46%40%3Cdev.calcite.apache.org%3E > >>>>> > >>>>> On Wed, Feb 26, 2020 at 3:12 PM Chunwei Lei <[email protected]> > >>>> wrote: > >>>>> > >>>>>> Thanks for pointing out this, Ruben. I also have this question. > >>>>>> > >>>>>> But in our scrum, we can merge commits to master at the moment we > have > >>>> a > >>>>>> release branch. > >>>>>> > >>>>>> > >>>>>> Best, > >>>>>> Chunwei > >>>>>> > >>>>>> > >>>>>> On Wed, Feb 26, 2020 at 8:52 PM Ruben Q L <[email protected]> > wrote: > >>>>>> > >>>>>>> Hello everyone, > >>>>>>> > >>>>>>> as you know, we are in the middle of the release process for 1.22 > >>>> (btw, > >>>>>>> thanks Danny for your effort as release manager). > >>>>>>> However, if I am not mistaken I can see that some PRs have been > >>>> merged > >>>>>>> during this time, at least [1] and [2]. I am wondering if during > this > >>>>>>> process (from the build of the first release candidate to the final > >>>>>>> approval of the release), we should not be in some kind of "code > >>>> freeze", > >>>>>>> where commits are not allowed, unless they are explicitly approved > >>>>>>> (ultimately by the release manager, I guess) in order to solve > issues > >>>>>> with > >>>>>>> the release candidates (e.g. [3]). Is there any rule / guideline > >>>> about > >>>>>>> this? > >>>>>>> > >>>>>>> Best regards, > >>>>>>> Ruben. > >>>>>>> > >>>>>>> [1] https://issues.apache.org/jira/browse/CALCITE-3817 > >>>>>>> [2] https://issues.apache.org/jira/browse/CALCITE-3734 > >>>>>>> < > >>>>>>> > >>>>>> > >>>> > >> > https://slack-redir.net/link?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FCALCITE-3734&v=3 > >>>>>>>> > >>>>>>> [3] https://issues.apache.org/jira/browse/CALCITE-3822 > >>>>>>> > >>>>>> > >>>> > >> > >> > >
