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 >>>>> >>>> >>
