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