[DISCUSS] Code freeze policy during release

[Ruben Q L <ru...@gmail.com>]

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

Re: [DISCUSS] Code freeze policy during release

[Chunwei Lei <ch...@gmail.com>]

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 <jh...@apache.org> 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 <
> jcamacho@apache.org> 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 <jh...@apache.org> 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
> >> <jc...@cloudera.com.INVALID> 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 <mm...@apache.org>
> 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
> >>>> mmior@apache.org
> >>>>
> >>>> Le mer. 26 févr. 2020 à 09:33, Stamatis Zampetakis <zabetak@gmail.com
> >
> >> 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 <ch...@gmail.com>
> >>>> 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 <ru...@gmail.com>
> 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
> >>>>>>>
> >>>>>>
> >>>>
> >>
> >>
>
>

Re: [DISCUSS] Code freeze policy during release

[Julian Hyde <jh...@apache.org>]

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 <jc...@apache.org> 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 <jh...@apache.org> 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
>> <jc...@cloudera.com.INVALID> 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 <mm...@apache.org> 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
>>>> mmior@apache.org
>>>> 
>>>> Le mer. 26 févr. 2020 à 09:33, Stamatis Zampetakis <za...@gmail.com>
>> 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 <ch...@gmail.com>
>>>> 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 <ru...@gmail.com> 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
>>>>>>> 
>>>>>> 
>>>> 
>> 
>> 

Re: [DISCUSS] Code freeze policy during release

[Jesus Camacho Rodriguez <jc...@apache.org>]

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 <jh...@apache.org> 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
> <jc...@cloudera.com.INVALID> 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 <mm...@apache.org> 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
> >> mmior@apache.org
> >>
> >> Le mer. 26 févr. 2020 à 09:33, Stamatis Zampetakis <za...@gmail.com>
> 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 <ch...@gmail.com>
> >> 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 <ru...@gmail.com> 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
> >>>>>
> >>>>
> >>
>
>

Re: [DISCUSS] Code freeze policy during release

[Julian Hyde <jh...@apache.org>]

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 <jc...@cloudera.com.INVALID> 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 <mm...@apache.org> 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
>> mmior@apache.org
>> 
>> Le mer. 26 févr. 2020 à 09:33, Stamatis Zampetakis <za...@gmail.com> 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 <ch...@gmail.com>
>> 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 <ru...@gmail.com> 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
>>>>> 
>>>> 
>> 

Re: [DISCUSS] Code freeze policy during release

[Jesus Camacho Rodriguez <jc...@cloudera.com.INVALID>]

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 <mm...@apache.org> 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
> mmior@apache.org
>
> Le mer. 26 févr. 2020 à 09:33, Stamatis Zampetakis <za...@gmail.com> 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 <ch...@gmail.com>
> 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 <ru...@gmail.com> 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
> > > >
> > >
>

Re: [DISCUSS] Code freeze policy during release

[Michael Mior <mm...@apache.org>]

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
mmior@apache.org

Le mer. 26 févr. 2020 à 09:33, Stamatis Zampetakis <za...@gmail.com> 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 <ch...@gmail.com> 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 <ru...@gmail.com> 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
> > >
> >

Re: [DISCUSS] Code freeze policy during release

[Julian Hyde <jh...@apache.org>]

This thread sums up the rationale:

https://lists.apache.org/thread.html/b49639d926e64955cdca49aca1d2183f00812b54d2d5957499d39c9f%40%3Cdev.calcite.apache.org%3E

If someone commits to master during the release process we either have
to rebase master, do a merge commit, or have a release that is not a
direct ancestor of the master branch going forward. None of these is
particularly attractive. So we ask people to suspend commits.

(For fans of the CAP theorem: we choose consistency over availability.)

On Wed, Feb 26, 2020 at 6:33 AM Stamatis Zampetakis <za...@gmail.com> wrote:
>
> 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 <ch...@gmail.com> 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 <ru...@gmail.com> 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
> > >
> >

Re: [DISCUSS] Code freeze policy during release

[Stamatis Zampetakis <za...@gmail.com>]

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 <ch...@gmail.com> 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 <ru...@gmail.com> 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
> >
>

Re: [DISCUSS] Code freeze policy during release

[Chunwei Lei <ch...@gmail.com>]

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 <ru...@gmail.com> 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
>