You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Alexander Murmann <am...@apache.org> on 2019/01/29 21:50:01 UTC
Geode 1.9 Release Manager
Hi everyone!
February 1st is approaching rapidly which means it's almost time to cut the
1.9 release. Who is interested in being the release manager for 1.9?
Thank you!
Re: Geode 1.9 Release Manager
Posted by Nabarun Nag <nn...@apache.org>.
Ahhh. Thank you Alexander. That makes sense.
I agree with you, as I mentioned in an earlier email
*I agree with the cutting the release branch, keep it sanitized from
additional commits going into develop but ensure only these important
critical fixes mentioned above in this chain makes it into the release
branch.*
Regards
Naba
On Thu, Feb 14, 2019 at 1:42 PM Alexander Murmann <aj...@gmail.com>
wrote:
> Naba, I agree that we should fix these before releasing. I was talking
> about the trade offs between fixing on develop and then branch or branching
> first and then fixing on develop and release branch.
>
> On Thu, Feb 14, 2019 at 1:18 PM Nabarun Nag <nn...@pivotal.io> wrote:
>
> > I agree but not putting in these fixes means that we are releasing with
> > serious known issues in the product. Hence in my opinion this risk is
> > acceptable.
> >
> > Regards
> > Naba
> >
> > On Thu, Feb 14, 2019 at 12:34 PM Alexander Murmann <am...@apache.org>
> > wrote:
> >
> > > >
> > > > For the second part, I am not sure how it was determined that fixes
> for
> > > > GEODE-6391, GEODE-6393, GEODE-6369, GEODE-6404 contains risk of
> > > introducing
> > > > more failures. Are we lacking tests , reviews etc. I apologize but I
> > was
> > > > not able to understand.
> > > >
> > > Not sure if you were responding to me. My concern wasn't that these
> fixes
> > > introduce a regression, but that other changes happening on develop
> might
> > > introduce new issues.
> > >
> > > That said, every change always carries some amount of risk to
> introduce a
> > > new issue on any codebase, Even 100% test coverage can only make it a
> lot
> > > less likely, but not remove the risk entirely.
> > >
> > > On Thu, Feb 14, 2019 at 12:00 PM Nabarun Nag <nn...@pivotal.io> wrote:
> > >
> > > > I could not find any DISCUSS mails about not blocking a release. I
> may
> > be
> > > > wrong, I apologize for that but could point me to the mail /
> > > documentation
> > > > about the release management.
> > > >
> > > > Regards
> > > > Naba
> > > >
> > > > On Thu, Feb 14, 2019 at 11:52 AM Sai Boorlagadda <
> > > > sai.boorlagadda@gmail.com>
> > > > wrote:
> > > >
> > > > > Did we not agreed that we won't be blocking a release to include
> > fixes
> > > as
> > > > > we are in a fixed release schedule?
> > > > >
> > > > >
> > > > > On Thu, Feb 14, 2019 at 11:36 AM Alexander Murmann <
> > > amurmann@apache.org>
> > > > > wrote:
> > > > >
> > > > > > Usually I am a proponent of cutting a branch and then fixing
> things
> > > on
> > > > > > there where things are more stable. In this case we seem to have
> a
> > > > large
> > > > > > number of fairly serious concerns. Do we think the cost of
> putting
> > > this
> > > > > > many fixes on develop + the release branch out-weights the
> benefit
> > of
> > > > > less
> > > > > > risk of new issues being introduced?
> > > > > >
> > > > > > Thoughts?
> > > > > >
> > > > > > Thank you, Sai for taking over!
> > > > > >
> > > > > > On Thu, Feb 14, 2019 at 10:32 AM Sai Boorlagadda <
> > > > > > sai.boorlagadda@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > I volunteer to be the release manager for 1.9.
> > > > > > >
> > > > > > > Sai
> > > > > > >
> > > > > > > On Wed, Feb 13, 2019 at 7:48 PM Alexander Murmann <
> > > > amurmann@apache.org
> > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > If there are no other takers, I can act as release manager
> for
> > > 1.9
> > > > > and
> > > > > > > will
> > > > > > > > cut a release branch this week.
> > > > > > > >
> > > > > > > >
> > > > > > > > On Tue, Jan 29, 2019 at 1:50 PM Alexander Murmann <
> > > > > amurmann@apache.org
> > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hi everyone!
> > > > > > > > >
> > > > > > > > > February 1st is approaching rapidly which means it's almost
> > > time
> > > > to
> > > > > > cut
> > > > > > > > > the 1.9 release. Who is interested in being the release
> > manager
> > > > for
> > > > > > > 1.9?
> > > > > > > > >
> > > > > > > > > Thank you!
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
>
> --
> Alexander J. Murmann
> (650) 283-1933
>
Re: Geode 1.9 Release Manager
Posted by Alexander Murmann <aj...@gmail.com>.
Naba, I agree that we should fix these before releasing. I was talking
about the trade offs between fixing on develop and then branch or branching
first and then fixing on develop and release branch.
On Thu, Feb 14, 2019 at 1:18 PM Nabarun Nag <nn...@pivotal.io> wrote:
> I agree but not putting in these fixes means that we are releasing with
> serious known issues in the product. Hence in my opinion this risk is
> acceptable.
>
> Regards
> Naba
>
> On Thu, Feb 14, 2019 at 12:34 PM Alexander Murmann <am...@apache.org>
> wrote:
>
> > >
> > > For the second part, I am not sure how it was determined that fixes for
> > > GEODE-6391, GEODE-6393, GEODE-6369, GEODE-6404 contains risk of
> > introducing
> > > more failures. Are we lacking tests , reviews etc. I apologize but I
> was
> > > not able to understand.
> > >
> > Not sure if you were responding to me. My concern wasn't that these fixes
> > introduce a regression, but that other changes happening on develop might
> > introduce new issues.
> >
> > That said, every change always carries some amount of risk to introduce a
> > new issue on any codebase, Even 100% test coverage can only make it a lot
> > less likely, but not remove the risk entirely.
> >
> > On Thu, Feb 14, 2019 at 12:00 PM Nabarun Nag <nn...@pivotal.io> wrote:
> >
> > > I could not find any DISCUSS mails about not blocking a release. I may
> be
> > > wrong, I apologize for that but could point me to the mail /
> > documentation
> > > about the release management.
> > >
> > > Regards
> > > Naba
> > >
> > > On Thu, Feb 14, 2019 at 11:52 AM Sai Boorlagadda <
> > > sai.boorlagadda@gmail.com>
> > > wrote:
> > >
> > > > Did we not agreed that we won't be blocking a release to include
> fixes
> > as
> > > > we are in a fixed release schedule?
> > > >
> > > >
> > > > On Thu, Feb 14, 2019 at 11:36 AM Alexander Murmann <
> > amurmann@apache.org>
> > > > wrote:
> > > >
> > > > > Usually I am a proponent of cutting a branch and then fixing things
> > on
> > > > > there where things are more stable. In this case we seem to have a
> > > large
> > > > > number of fairly serious concerns. Do we think the cost of putting
> > this
> > > > > many fixes on develop + the release branch out-weights the benefit
> of
> > > > less
> > > > > risk of new issues being introduced?
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > Thank you, Sai for taking over!
> > > > >
> > > > > On Thu, Feb 14, 2019 at 10:32 AM Sai Boorlagadda <
> > > > > sai.boorlagadda@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > I volunteer to be the release manager for 1.9.
> > > > > >
> > > > > > Sai
> > > > > >
> > > > > > On Wed, Feb 13, 2019 at 7:48 PM Alexander Murmann <
> > > amurmann@apache.org
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > If there are no other takers, I can act as release manager for
> > 1.9
> > > > and
> > > > > > will
> > > > > > > cut a release branch this week.
> > > > > > >
> > > > > > >
> > > > > > > On Tue, Jan 29, 2019 at 1:50 PM Alexander Murmann <
> > > > amurmann@apache.org
> > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hi everyone!
> > > > > > > >
> > > > > > > > February 1st is approaching rapidly which means it's almost
> > time
> > > to
> > > > > cut
> > > > > > > > the 1.9 release. Who is interested in being the release
> manager
> > > for
> > > > > > 1.9?
> > > > > > > >
> > > > > > > > Thank you!
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
--
Alexander J. Murmann
(650) 283-1933
Re: Geode 1.9 Release Manager
Posted by Nabarun Nag <nn...@pivotal.io>.
I agree but not putting in these fixes means that we are releasing with
serious known issues in the product. Hence in my opinion this risk is
acceptable.
Regards
Naba
On Thu, Feb 14, 2019 at 12:34 PM Alexander Murmann <am...@apache.org>
wrote:
> >
> > For the second part, I am not sure how it was determined that fixes for
> > GEODE-6391, GEODE-6393, GEODE-6369, GEODE-6404 contains risk of
> introducing
> > more failures. Are we lacking tests , reviews etc. I apologize but I was
> > not able to understand.
> >
> Not sure if you were responding to me. My concern wasn't that these fixes
> introduce a regression, but that other changes happening on develop might
> introduce new issues.
>
> That said, every change always carries some amount of risk to introduce a
> new issue on any codebase, Even 100% test coverage can only make it a lot
> less likely, but not remove the risk entirely.
>
> On Thu, Feb 14, 2019 at 12:00 PM Nabarun Nag <nn...@pivotal.io> wrote:
>
> > I could not find any DISCUSS mails about not blocking a release. I may be
> > wrong, I apologize for that but could point me to the mail /
> documentation
> > about the release management.
> >
> > Regards
> > Naba
> >
> > On Thu, Feb 14, 2019 at 11:52 AM Sai Boorlagadda <
> > sai.boorlagadda@gmail.com>
> > wrote:
> >
> > > Did we not agreed that we won't be blocking a release to include fixes
> as
> > > we are in a fixed release schedule?
> > >
> > >
> > > On Thu, Feb 14, 2019 at 11:36 AM Alexander Murmann <
> amurmann@apache.org>
> > > wrote:
> > >
> > > > Usually I am a proponent of cutting a branch and then fixing things
> on
> > > > there where things are more stable. In this case we seem to have a
> > large
> > > > number of fairly serious concerns. Do we think the cost of putting
> this
> > > > many fixes on develop + the release branch out-weights the benefit of
> > > less
> > > > risk of new issues being introduced?
> > > >
> > > > Thoughts?
> > > >
> > > > Thank you, Sai for taking over!
> > > >
> > > > On Thu, Feb 14, 2019 at 10:32 AM Sai Boorlagadda <
> > > > sai.boorlagadda@gmail.com>
> > > > wrote:
> > > >
> > > > > I volunteer to be the release manager for 1.9.
> > > > >
> > > > > Sai
> > > > >
> > > > > On Wed, Feb 13, 2019 at 7:48 PM Alexander Murmann <
> > amurmann@apache.org
> > > >
> > > > > wrote:
> > > > >
> > > > > > If there are no other takers, I can act as release manager for
> 1.9
> > > and
> > > > > will
> > > > > > cut a release branch this week.
> > > > > >
> > > > > >
> > > > > > On Tue, Jan 29, 2019 at 1:50 PM Alexander Murmann <
> > > amurmann@apache.org
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Hi everyone!
> > > > > > >
> > > > > > > February 1st is approaching rapidly which means it's almost
> time
> > to
> > > > cut
> > > > > > > the 1.9 release. Who is interested in being the release manager
> > for
> > > > > 1.9?
> > > > > > >
> > > > > > > Thank you!
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Geode 1.9 Release Manager
Posted by Alexander Murmann <am...@apache.org>.
>
> For the second part, I am not sure how it was determined that fixes for
> GEODE-6391, GEODE-6393, GEODE-6369, GEODE-6404 contains risk of introducing
> more failures. Are we lacking tests , reviews etc. I apologize but I was
> not able to understand.
>
Not sure if you were responding to me. My concern wasn't that these fixes
introduce a regression, but that other changes happening on develop might
introduce new issues.
That said, every change always carries some amount of risk to introduce a
new issue on any codebase, Even 100% test coverage can only make it a lot
less likely, but not remove the risk entirely.
On Thu, Feb 14, 2019 at 12:00 PM Nabarun Nag <nn...@pivotal.io> wrote:
> I could not find any DISCUSS mails about not blocking a release. I may be
> wrong, I apologize for that but could point me to the mail / documentation
> about the release management.
>
> Regards
> Naba
>
> On Thu, Feb 14, 2019 at 11:52 AM Sai Boorlagadda <
> sai.boorlagadda@gmail.com>
> wrote:
>
> > Did we not agreed that we won't be blocking a release to include fixes as
> > we are in a fixed release schedule?
> >
> >
> > On Thu, Feb 14, 2019 at 11:36 AM Alexander Murmann <am...@apache.org>
> > wrote:
> >
> > > Usually I am a proponent of cutting a branch and then fixing things on
> > > there where things are more stable. In this case we seem to have a
> large
> > > number of fairly serious concerns. Do we think the cost of putting this
> > > many fixes on develop + the release branch out-weights the benefit of
> > less
> > > risk of new issues being introduced?
> > >
> > > Thoughts?
> > >
> > > Thank you, Sai for taking over!
> > >
> > > On Thu, Feb 14, 2019 at 10:32 AM Sai Boorlagadda <
> > > sai.boorlagadda@gmail.com>
> > > wrote:
> > >
> > > > I volunteer to be the release manager for 1.9.
> > > >
> > > > Sai
> > > >
> > > > On Wed, Feb 13, 2019 at 7:48 PM Alexander Murmann <
> amurmann@apache.org
> > >
> > > > wrote:
> > > >
> > > > > If there are no other takers, I can act as release manager for 1.9
> > and
> > > > will
> > > > > cut a release branch this week.
> > > > >
> > > > >
> > > > > On Tue, Jan 29, 2019 at 1:50 PM Alexander Murmann <
> > amurmann@apache.org
> > > >
> > > > > wrote:
> > > > >
> > > > > > Hi everyone!
> > > > > >
> > > > > > February 1st is approaching rapidly which means it's almost time
> to
> > > cut
> > > > > > the 1.9 release. Who is interested in being the release manager
> for
> > > > 1.9?
> > > > > >
> > > > > > Thank you!
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Geode 1.9 Release Manager
Posted by Michael Oleske <mo...@pivotal.io>.
I have merged https://github.com/apache/geode/pull/3195 just now.
-michael
On Fri, Feb 15, 2019 at 8:27 AM Sai Boorlagadda <sa...@gmail.com>
wrote:
> BTW, Is PR #3195 is planned to merge today?
>
> On Fri, Feb 15, 2019 at 7:53 AM Sai Boorlagadda <sai.boorlagadda@gmail.com
> >
> wrote:
>
> > I am planning to cut the1.9 release branch today after merging this
> > PR #3195 which is reverting changes to GEODE-6334 & GEODE-6345.
> >
> > Is there anything other than that I should be aware of?
> >
> > Here is the list of issues that were requested to be included into 1.9.
> > If there is any plan to merge any of these today let me know and
> > I can cut the branch after that.
> >
> > GEODE-6334 - CachePerfStats operation count stats may wrap to negative
> > values
> >
> > GEODE-6345 - StatSamplerStats jvmPauses stat may wrap to negative value
> >
> > GEODE-6369 - Cache-creation failure after a successful auto-reconnect
> > causes subsequent NPE
> >
> > GEODE-6391 - Event IDs must be included in the PartitioneRegion messages
> >
> > GEODE-6404 - review use of computeIfAbsent across the code base
> >
> >
> > (experimental and dropped)
> >
> > GEODE-6393 - Replace synchronization lock with AtomicReference for
> > InternalLocator
> >
> >
> > -
> >
> > Sai
> >
> > On Thu, Feb 14, 2019 at 3:21 PM Sai Boorlagadda <
> sai.boorlagadda@gmail.com>
> > wrote:
> >
> >> I didn't mean blocking a release but the release process (including
> >> cutting the branch).
> >>
> >>
> >> I thought there was a consensus about strictly cutting a
> >>
> >> branch[1] with our new fixed minor release cadence and
> >>
> >> only allow critical fixes.
> >>
> >>
> >> I assumed that any critical fixes that are allowed onto the
> >>
> >> release branch are the ones that are identified on the branch
> >>
> >> after it is cut and not the ones that are already known.
> >>
> >>
> >> Correct me if my understanding is wrong.
> >>
> >>
> >> [1]
> >>
> https://lists.apache.org/thread.html/d36a63c3794d13506ecad3d52a2aca938dcf0f8509b61860bbbc50cd@%3Cdev.geode.apache.org%3E
> >>
> >> On Thu, Feb 14, 2019 at 12:00 PM Nabarun Nag <nn...@pivotal.io> wrote:
> >>
> >>> I could not find any DISCUSS mails about not blocking a release. I may
> be
> >>> wrong, I apologize for that but could point me to the mail /
> >>> documentation
> >>> about the release management.
> >>>
> >>> Regards
> >>> Naba
> >>>
> >>> On Thu, Feb 14, 2019 at 11:52 AM Sai Boorlagadda <
> >>> sai.boorlagadda@gmail.com>
> >>> wrote:
> >>>
> >>> > Did we not agreed that we won't be blocking a release to include
> fixes
> >>> as
> >>> > we are in a fixed release schedule?
> >>> >
> >>> >
> >>> > On Thu, Feb 14, 2019 at 11:36 AM Alexander Murmann <
> >>> amurmann@apache.org>
> >>> > wrote:
> >>> >
> >>> > > Usually I am a proponent of cutting a branch and then fixing things
> >>> on
> >>> > > there where things are more stable. In this case we seem to have a
> >>> large
> >>> > > number of fairly serious concerns. Do we think the cost of putting
> >>> this
> >>> > > many fixes on develop + the release branch out-weights the benefit
> of
> >>> > less
> >>> > > risk of new issues being introduced?
> >>> > >
> >>> > > Thoughts?
> >>> > >
> >>> > > Thank you, Sai for taking over!
> >>> > >
> >>> > > On Thu, Feb 14, 2019 at 10:32 AM Sai Boorlagadda <
> >>> > > sai.boorlagadda@gmail.com>
> >>> > > wrote:
> >>> > >
> >>> > > > I volunteer to be the release manager for 1.9.
> >>> > > >
> >>> > > > Sai
> >>> > > >
> >>> > > > On Wed, Feb 13, 2019 at 7:48 PM Alexander Murmann <
> >>> amurmann@apache.org
> >>> > >
> >>> > > > wrote:
> >>> > > >
> >>> > > > > If there are no other takers, I can act as release manager for
> >>> 1.9
> >>> > and
> >>> > > > will
> >>> > > > > cut a release branch this week.
> >>> > > > >
> >>> > > > >
> >>> > > > > On Tue, Jan 29, 2019 at 1:50 PM Alexander Murmann <
> >>> > amurmann@apache.org
> >>> > > >
> >>> > > > > wrote:
> >>> > > > >
> >>> > > > > > Hi everyone!
> >>> > > > > >
> >>> > > > > > February 1st is approaching rapidly which means it's almost
> >>> time to
> >>> > > cut
> >>> > > > > > the 1.9 release. Who is interested in being the release
> >>> manager for
> >>> > > > 1.9?
> >>> > > > > >
> >>> > > > > > Thank you!
> >>> > > > > >
> >>> > > > >
> >>> > > >
> >>> > >
> >>> >
> >>>
> >>
>
Re: Geode 1.9 Release Manager
Posted by Sai Boorlagadda <sa...@gmail.com>.
BTW, Is PR #3195 is planned to merge today?
On Fri, Feb 15, 2019 at 7:53 AM Sai Boorlagadda <sa...@gmail.com>
wrote:
> I am planning to cut the1.9 release branch today after merging this
> PR #3195 which is reverting changes to GEODE-6334 & GEODE-6345.
>
> Is there anything other than that I should be aware of?
>
> Here is the list of issues that were requested to be included into 1.9.
> If there is any plan to merge any of these today let me know and
> I can cut the branch after that.
>
> GEODE-6334 - CachePerfStats operation count stats may wrap to negative
> values
>
> GEODE-6345 - StatSamplerStats jvmPauses stat may wrap to negative value
>
> GEODE-6369 - Cache-creation failure after a successful auto-reconnect
> causes subsequent NPE
>
> GEODE-6391 - Event IDs must be included in the PartitioneRegion messages
>
> GEODE-6404 - review use of computeIfAbsent across the code base
>
>
> (experimental and dropped)
>
> GEODE-6393 - Replace synchronization lock with AtomicReference for
> InternalLocator
>
>
> -
>
> Sai
>
> On Thu, Feb 14, 2019 at 3:21 PM Sai Boorlagadda <sa...@gmail.com>
> wrote:
>
>> I didn't mean blocking a release but the release process (including
>> cutting the branch).
>>
>>
>> I thought there was a consensus about strictly cutting a
>>
>> branch[1] with our new fixed minor release cadence and
>>
>> only allow critical fixes.
>>
>>
>> I assumed that any critical fixes that are allowed onto the
>>
>> release branch are the ones that are identified on the branch
>>
>> after it is cut and not the ones that are already known.
>>
>>
>> Correct me if my understanding is wrong.
>>
>>
>> [1]
>> https://lists.apache.org/thread.html/d36a63c3794d13506ecad3d52a2aca938dcf0f8509b61860bbbc50cd@%3Cdev.geode.apache.org%3E
>>
>> On Thu, Feb 14, 2019 at 12:00 PM Nabarun Nag <nn...@pivotal.io> wrote:
>>
>>> I could not find any DISCUSS mails about not blocking a release. I may be
>>> wrong, I apologize for that but could point me to the mail /
>>> documentation
>>> about the release management.
>>>
>>> Regards
>>> Naba
>>>
>>> On Thu, Feb 14, 2019 at 11:52 AM Sai Boorlagadda <
>>> sai.boorlagadda@gmail.com>
>>> wrote:
>>>
>>> > Did we not agreed that we won't be blocking a release to include fixes
>>> as
>>> > we are in a fixed release schedule?
>>> >
>>> >
>>> > On Thu, Feb 14, 2019 at 11:36 AM Alexander Murmann <
>>> amurmann@apache.org>
>>> > wrote:
>>> >
>>> > > Usually I am a proponent of cutting a branch and then fixing things
>>> on
>>> > > there where things are more stable. In this case we seem to have a
>>> large
>>> > > number of fairly serious concerns. Do we think the cost of putting
>>> this
>>> > > many fixes on develop + the release branch out-weights the benefit of
>>> > less
>>> > > risk of new issues being introduced?
>>> > >
>>> > > Thoughts?
>>> > >
>>> > > Thank you, Sai for taking over!
>>> > >
>>> > > On Thu, Feb 14, 2019 at 10:32 AM Sai Boorlagadda <
>>> > > sai.boorlagadda@gmail.com>
>>> > > wrote:
>>> > >
>>> > > > I volunteer to be the release manager for 1.9.
>>> > > >
>>> > > > Sai
>>> > > >
>>> > > > On Wed, Feb 13, 2019 at 7:48 PM Alexander Murmann <
>>> amurmann@apache.org
>>> > >
>>> > > > wrote:
>>> > > >
>>> > > > > If there are no other takers, I can act as release manager for
>>> 1.9
>>> > and
>>> > > > will
>>> > > > > cut a release branch this week.
>>> > > > >
>>> > > > >
>>> > > > > On Tue, Jan 29, 2019 at 1:50 PM Alexander Murmann <
>>> > amurmann@apache.org
>>> > > >
>>> > > > > wrote:
>>> > > > >
>>> > > > > > Hi everyone!
>>> > > > > >
>>> > > > > > February 1st is approaching rapidly which means it's almost
>>> time to
>>> > > cut
>>> > > > > > the 1.9 release. Who is interested in being the release
>>> manager for
>>> > > > 1.9?
>>> > > > > >
>>> > > > > > Thank you!
>>> > > > > >
>>> > > > >
>>> > > >
>>> > >
>>> >
>>>
>>
Re: Geode 1.9 Release Manager
Posted by Dave Barnes <db...@pivotal.io>.
Just tag, I think.
On Fri, Feb 15, 2019 at 2:15 PM Sai Boorlagadda <sa...@gmail.com>
wrote:
> There are about 8[1] issues in JIRA that are in open/in-progress/re-opened
> status for 1.9.0.
> Can I request all the devs to reflect JIRA with current status?
>
> [1]
> https://issues.apache.org/jira/browse/GEODE-6107?jql=project%20%3D%20GEODE%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20fixVersion%20%3D%201.9.0
>
> Sai
>
> On Fri, Feb 15, 2019 at 12:56 PM Sai Boorlagadda <
> sai.boorlagadda@gmail.com> wrote:
>
>> Thanks Dave. I keep a note to include Geode Native.
>>
>> As we are including only a source release for Geode Native
>> do we need to create a release branch? Or just tag it?
>>
>> Though we will eventually be tagging Geode & Geode Examples repos.
>> So until it gets released I think as a place holder I can go ahead still
>> create a release branch for Geode Native?
>>
>> Sai
>>
>>
>> On Fri, Feb 15, 2019 at 9:51 AM Dave Barnes <db...@apache.org> wrote:
>>
>>> Sai,
>>> The Geode 1.8 release included (for the first time) a source snapshot of
>>> the geode-native repo.
>>> As far as I know, the same treatment would be in order for v1.9.
>>>
>>>
>>> On Fri, Feb 15, 2019 at 9:01 AM Bruce Schuchardt <bschuchardt@pivotal.io
>>> >
>>> wrote:
>>>
>>> > I would like to get GEODE-6369 into the next release but that can be
>>> > done in a cherry-pick after I finish testing. The changes are in in
>>> > discovery, joining the cluster and in failure detection so they've
>>> > needed extensive testing.
>>> >
>>> > On 2/15/19 7:53 AM, Sai Boorlagadda wrote:
>>> > > I am planning to cut the1.9 release branch today after merging this
>>> > > PR #3195 which is reverting changes to GEODE-6334 & GEODE-6345.
>>> > >
>>> > > Is there anything other than that I should be aware of?
>>> > >
>>> > > Here is the list of issues that were requested to be included into
>>> 1.9.
>>> > > If there is any plan to merge any of these today let me know and
>>> > > I can cut the branch after that.
>>> > >
>>> > > GEODE-6334 - CachePerfStats operation count stats may wrap to
>>> negative
>>> > > values
>>> > >
>>> > > GEODE-6345 - StatSamplerStats jvmPauses stat may wrap to negative
>>> value
>>> > >
>>> > > GEODE-6369 - Cache-creation failure after a successful auto-reconnect
>>> > > causes subsequent NPE
>>> > >
>>> > > GEODE-6391 - Event IDs must be included in the PartitioneRegion
>>> messages
>>> > >
>>> > > GEODE-6404 - review use of computeIfAbsent across the code base
>>> > >
>>> > >
>>> > > (experimental and dropped)
>>> > >
>>> > > GEODE-6393 - Replace synchronization lock with AtomicReference for
>>> > > InternalLocator
>>> > >
>>> > >
>>> > > -
>>> > >
>>> > > Sai
>>> > >
>>> > > On Thu, Feb 14, 2019 at 3:21 PM Sai Boorlagadda <
>>> > sai.boorlagadda@gmail.com>
>>> > > wrote:
>>> > >
>>> > >> I didn't mean blocking a release but the release process (including
>>> > >> cutting the branch).
>>> > >>
>>> > >>
>>> > >> I thought there was a consensus about strictly cutting a
>>> > >>
>>> > >> branch[1] with our new fixed minor release cadence and
>>> > >>
>>> > >> only allow critical fixes.
>>> > >>
>>> > >>
>>> > >> I assumed that any critical fixes that are allowed onto the
>>> > >>
>>> > >> release branch are the ones that are identified on the branch
>>> > >>
>>> > >> after it is cut and not the ones that are already known.
>>> > >>
>>> > >>
>>> > >> Correct me if my understanding is wrong.
>>> > >>
>>> > >>
>>> > >> [1]
>>> > >>
>>> >
>>> https://lists.apache.org/thread.html/d36a63c3794d13506ecad3d52a2aca938dcf0f8509b61860bbbc50cd@%3Cdev.geode.apache.org%3E
>>> > >>
>>> > >> On Thu, Feb 14, 2019 at 12:00 PM Nabarun Nag <nn...@pivotal.io>
>>> wrote:
>>> > >>
>>> > >>> I could not find any DISCUSS mails about not blocking a release. I
>>> may
>>> > be
>>> > >>> wrong, I apologize for that but could point me to the mail /
>>> > documentation
>>> > >>> about the release management.
>>> > >>>
>>> > >>> Regards
>>> > >>> Naba
>>> > >>>
>>> > >>> On Thu, Feb 14, 2019 at 11:52 AM Sai Boorlagadda <
>>> > >>> sai.boorlagadda@gmail.com>
>>> > >>> wrote:
>>> > >>>
>>> > >>>> Did we not agreed that we won't be blocking a release to include
>>> fixes
>>> > >>> as
>>> > >>>> we are in a fixed release schedule?
>>> > >>>>
>>> > >>>>
>>> > >>>> On Thu, Feb 14, 2019 at 11:36 AM Alexander Murmann <
>>> > amurmann@apache.org
>>> > >>>>
>>> > >>>> wrote:
>>> > >>>>
>>> > >>>>> Usually I am a proponent of cutting a branch and then fixing
>>> things
>>> > on
>>> > >>>>> there where things are more stable. In this case we seem to have
>>> a
>>> > >>> large
>>> > >>>>> number of fairly serious concerns. Do we think the cost of
>>> putting
>>> > >>> this
>>> > >>>>> many fixes on develop + the release branch out-weights the
>>> benefit of
>>> > >>>> less
>>> > >>>>> risk of new issues being introduced?
>>> > >>>>>
>>> > >>>>> Thoughts?
>>> > >>>>>
>>> > >>>>> Thank you, Sai for taking over!
>>> > >>>>>
>>> > >>>>> On Thu, Feb 14, 2019 at 10:32 AM Sai Boorlagadda <
>>> > >>>>> sai.boorlagadda@gmail.com>
>>> > >>>>> wrote:
>>> > >>>>>
>>> > >>>>>> I volunteer to be the release manager for 1.9.
>>> > >>>>>>
>>> > >>>>>> Sai
>>> > >>>>>>
>>> > >>>>>> On Wed, Feb 13, 2019 at 7:48 PM Alexander Murmann <
>>> > >>> amurmann@apache.org
>>> > >>>>>> wrote:
>>> > >>>>>>
>>> > >>>>>>> If there are no other takers, I can act as release manager for
>>> 1.9
>>> > >>>> and
>>> > >>>>>> will
>>> > >>>>>>> cut a release branch this week.
>>> > >>>>>>>
>>> > >>>>>>>
>>> > >>>>>>> On Tue, Jan 29, 2019 at 1:50 PM Alexander Murmann <
>>> > >>>> amurmann@apache.org
>>> > >>>>>>> wrote:
>>> > >>>>>>>
>>> > >>>>>>>> Hi everyone!
>>> > >>>>>>>>
>>> > >>>>>>>> February 1st is approaching rapidly which means it's almost
>>> > >>> time to
>>> > >>>>> cut
>>> > >>>>>>>> the 1.9 release. Who is interested in being the release
>>> manager
>>> > >>> for
>>> > >>>>>> 1.9?
>>> > >>>>>>>> Thank you!
>>> > >>>>>>>>
>>> >
>>>
>>
Re: Geode 1.9 Release Manager
Posted by Patrick Rhomberg <pr...@pivotal.io>.
I would love for GEODE-6399 / PR #3190 to be included in this release.
This PR resolves the earlier issues we had delegating dependencies to the
geode-all-bom BOM and massively reduces the POMs for each module we publish.
As it is, the published POMs are functional, and I understand that such
things are rarely human-inspected, but given that we haven't introduced the
<dependencyManagement> into our maven artifacts yet, I'd just as soon have
it done right when we do.
Not really a show-stopping issue, but it does involve our forward-facing
artifacts.
On Tue, Feb 19, 2019 at 2:20 PM Sai Boorlagadda <sa...@gmail.com>
wrote:
> Thanks Bruce. I will chery-pick this commit onto the new release branch.
>
> On Tue, Feb 19, 2019 at 1:06 PM Bruce Schuchardt <bs...@pivotal.io>
> wrote:
>
> > The fix for Geode-6369 has been pushed to develop. This needs to go in
> > the 1.9 release as it fixes some serious issues in auto-reconnect
> > including a distributed deadlock.
> >
> > On 2/15/19 2:15 PM, Sai Boorlagadda wrote:
> > > There are about 8[1] issues in JIRA that are in
> > open/in-progress/re-opened
> > > status for 1.9.0.
> > > Can I request all the devs to reflect JIRA with current status?
> > >
> > > [1]
> > >
> >
> https://issues.apache.org/jira/browse/GEODE-6107?jql=project%20%3D%20GEODE%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20fixVersion%20%3D%201.9.0
> > >
> > > Sai
> > >
> > > On Fri, Feb 15, 2019 at 12:56 PM Sai Boorlagadda <
> > sai.boorlagadda@gmail.com>
> > > wrote:
> > >
> > >> Thanks Dave. I keep a note to include Geode Native.
> > >>
> > >> As we are including only a source release for Geode Native
> > >> do we need to create a release branch? Or just tag it?
> > >>
> > >> Though we will eventually be tagging Geode & Geode Examples repos.
> > >> So until it gets released I think as a place holder I can go ahead
> still
> > >> create a release branch for Geode Native?
> > >>
> > >> Sai
> > >>
> > >>
> > >> On Fri, Feb 15, 2019 at 9:51 AM Dave Barnes <db...@apache.org>
> wrote:
> > >>
> > >>> Sai,
> > >>> The Geode 1.8 release included (for the first time) a source snapshot
> > of
> > >>> the geode-native repo.
> > >>> As far as I know, the same treatment would be in order for v1.9.
> > >>>
> > >>>
> > >>> On Fri, Feb 15, 2019 at 9:01 AM Bruce Schuchardt <
> > bschuchardt@pivotal.io>
> > >>> wrote:
> > >>>
> > >>>> I would like to get GEODE-6369 into the next release but that can be
> > >>>> done in a cherry-pick after I finish testing. The changes are in in
> > >>>> discovery, joining the cluster and in failure detection so they've
> > >>>> needed extensive testing.
> > >>>>
> > >>>> On 2/15/19 7:53 AM, Sai Boorlagadda wrote:
> > >>>>> I am planning to cut the1.9 release branch today after merging this
> > >>>>> PR #3195 which is reverting changes to GEODE-6334 & GEODE-6345.
> > >>>>>
> > >>>>> Is there anything other than that I should be aware of?
> > >>>>>
> > >>>>> Here is the list of issues that were requested to be included into
> > >>> 1.9.
> > >>>>> If there is any plan to merge any of these today let me know and
> > >>>>> I can cut the branch after that.
> > >>>>>
> > >>>>> GEODE-6334 - CachePerfStats operation count stats may wrap to
> > negative
> > >>>>> values
> > >>>>>
> > >>>>> GEODE-6345 - StatSamplerStats jvmPauses stat may wrap to negative
> > >>> value
> > >>>>> GEODE-6369 - Cache-creation failure after a successful
> auto-reconnect
> > >>>>> causes subsequent NPE
> > >>>>>
> > >>>>> GEODE-6391 - Event IDs must be included in the PartitioneRegion
> > >>> messages
> > >>>>> GEODE-6404 - review use of computeIfAbsent across the code base
> > >>>>>
> > >>>>>
> > >>>>> (experimental and dropped)
> > >>>>>
> > >>>>> GEODE-6393 - Replace synchronization lock with AtomicReference for
> > >>>>> InternalLocator
> > >>>>>
> > >>>>>
> > >>>>> -
> > >>>>>
> > >>>>> Sai
> > >>>>>
> > >>>>> On Thu, Feb 14, 2019 at 3:21 PM Sai Boorlagadda <
> > >>>> sai.boorlagadda@gmail.com>
> > >>>>> wrote:
> > >>>>>
> > >>>>>> I didn't mean blocking a release but the release process
> (including
> > >>>>>> cutting the branch).
> > >>>>>>
> > >>>>>>
> > >>>>>> I thought there was a consensus about strictly cutting a
> > >>>>>>
> > >>>>>> branch[1] with our new fixed minor release cadence and
> > >>>>>>
> > >>>>>> only allow critical fixes.
> > >>>>>>
> > >>>>>>
> > >>>>>> I assumed that any critical fixes that are allowed onto the
> > >>>>>>
> > >>>>>> release branch are the ones that are identified on the branch
> > >>>>>>
> > >>>>>> after it is cut and not the ones that are already known.
> > >>>>>>
> > >>>>>>
> > >>>>>> Correct me if my understanding is wrong.
> > >>>>>>
> > >>>>>>
> > >>>>>> [1]
> > >>>>>>
> > >>>
> >
> https://lists.apache.org/thread.html/d36a63c3794d13506ecad3d52a2aca938dcf0f8509b61860bbbc50cd@%3Cdev.geode.apache.org%3E
> > >>>>>> On Thu, Feb 14, 2019 at 12:00 PM Nabarun Nag <nn...@pivotal.io>
> > >>> wrote:
> > >>>>>>> I could not find any DISCUSS mails about not blocking a release.
> I
> > >>> may
> > >>>> be
> > >>>>>>> wrong, I apologize for that but could point me to the mail /
> > >>>> documentation
> > >>>>>>> about the release management.
> > >>>>>>>
> > >>>>>>> Regards
> > >>>>>>> Naba
> > >>>>>>>
> > >>>>>>> On Thu, Feb 14, 2019 at 11:52 AM Sai Boorlagadda <
> > >>>>>>> sai.boorlagadda@gmail.com>
> > >>>>>>> wrote:
> > >>>>>>>
> > >>>>>>>> Did we not agreed that we won't be blocking a release to include
> > >>> fixes
> > >>>>>>> as
> > >>>>>>>> we are in a fixed release schedule?
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> On Thu, Feb 14, 2019 at 11:36 AM Alexander Murmann <
> > >>>> amurmann@apache.org
> > >>>>>>>> wrote:
> > >>>>>>>>
> > >>>>>>>>> Usually I am a proponent of cutting a branch and then fixing
> > >>> things
> > >>>> on
> > >>>>>>>>> there where things are more stable. In this case we seem to
> have
> > a
> > >>>>>>> large
> > >>>>>>>>> number of fairly serious concerns. Do we think the cost of
> > putting
> > >>>>>>> this
> > >>>>>>>>> many fixes on develop + the release branch out-weights the
> > >>> benefit of
> > >>>>>>>> less
> > >>>>>>>>> risk of new issues being introduced?
> > >>>>>>>>>
> > >>>>>>>>> Thoughts?
> > >>>>>>>>>
> > >>>>>>>>> Thank you, Sai for taking over!
> > >>>>>>>>>
> > >>>>>>>>> On Thu, Feb 14, 2019 at 10:32 AM Sai Boorlagadda <
> > >>>>>>>>> sai.boorlagadda@gmail.com>
> > >>>>>>>>> wrote:
> > >>>>>>>>>
> > >>>>>>>>>> I volunteer to be the release manager for 1.9.
> > >>>>>>>>>>
> > >>>>>>>>>> Sai
> > >>>>>>>>>>
> > >>>>>>>>>> On Wed, Feb 13, 2019 at 7:48 PM Alexander Murmann <
> > >>>>>>> amurmann@apache.org
> > >>>>>>>>>> wrote:
> > >>>>>>>>>>
> > >>>>>>>>>>> If there are no other takers, I can act as release manager
> for
> > >>> 1.9
> > >>>>>>>> and
> > >>>>>>>>>> will
> > >>>>>>>>>>> cut a release branch this week.
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>> On Tue, Jan 29, 2019 at 1:50 PM Alexander Murmann <
> > >>>>>>>> amurmann@apache.org
> > >>>>>>>>>>> wrote:
> > >>>>>>>>>>>
> > >>>>>>>>>>>> Hi everyone!
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> February 1st is approaching rapidly which means it's almost
> > >>>>>>> time to
> > >>>>>>>>> cut
> > >>>>>>>>>>>> the 1.9 release. Who is interested in being the release
> > manager
> > >>>>>>> for
> > >>>>>>>>>> 1.9?
> > >>>>>>>>>>>> Thank you!
> > >>>>>>>>>>>>
> >
>
Re: Geode 1.9 Release Manager
Posted by Sai Boorlagadda <sa...@gmail.com>.
Thanks Bruce. I will chery-pick this commit onto the new release branch.
On Tue, Feb 19, 2019 at 1:06 PM Bruce Schuchardt <bs...@pivotal.io>
wrote:
> The fix for Geode-6369 has been pushed to develop. This needs to go in
> the 1.9 release as it fixes some serious issues in auto-reconnect
> including a distributed deadlock.
>
> On 2/15/19 2:15 PM, Sai Boorlagadda wrote:
> > There are about 8[1] issues in JIRA that are in
> open/in-progress/re-opened
> > status for 1.9.0.
> > Can I request all the devs to reflect JIRA with current status?
> >
> > [1]
> >
> https://issues.apache.org/jira/browse/GEODE-6107?jql=project%20%3D%20GEODE%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20fixVersion%20%3D%201.9.0
> >
> > Sai
> >
> > On Fri, Feb 15, 2019 at 12:56 PM Sai Boorlagadda <
> sai.boorlagadda@gmail.com>
> > wrote:
> >
> >> Thanks Dave. I keep a note to include Geode Native.
> >>
> >> As we are including only a source release for Geode Native
> >> do we need to create a release branch? Or just tag it?
> >>
> >> Though we will eventually be tagging Geode & Geode Examples repos.
> >> So until it gets released I think as a place holder I can go ahead still
> >> create a release branch for Geode Native?
> >>
> >> Sai
> >>
> >>
> >> On Fri, Feb 15, 2019 at 9:51 AM Dave Barnes <db...@apache.org> wrote:
> >>
> >>> Sai,
> >>> The Geode 1.8 release included (for the first time) a source snapshot
> of
> >>> the geode-native repo.
> >>> As far as I know, the same treatment would be in order for v1.9.
> >>>
> >>>
> >>> On Fri, Feb 15, 2019 at 9:01 AM Bruce Schuchardt <
> bschuchardt@pivotal.io>
> >>> wrote:
> >>>
> >>>> I would like to get GEODE-6369 into the next release but that can be
> >>>> done in a cherry-pick after I finish testing. The changes are in in
> >>>> discovery, joining the cluster and in failure detection so they've
> >>>> needed extensive testing.
> >>>>
> >>>> On 2/15/19 7:53 AM, Sai Boorlagadda wrote:
> >>>>> I am planning to cut the1.9 release branch today after merging this
> >>>>> PR #3195 which is reverting changes to GEODE-6334 & GEODE-6345.
> >>>>>
> >>>>> Is there anything other than that I should be aware of?
> >>>>>
> >>>>> Here is the list of issues that were requested to be included into
> >>> 1.9.
> >>>>> If there is any plan to merge any of these today let me know and
> >>>>> I can cut the branch after that.
> >>>>>
> >>>>> GEODE-6334 - CachePerfStats operation count stats may wrap to
> negative
> >>>>> values
> >>>>>
> >>>>> GEODE-6345 - StatSamplerStats jvmPauses stat may wrap to negative
> >>> value
> >>>>> GEODE-6369 - Cache-creation failure after a successful auto-reconnect
> >>>>> causes subsequent NPE
> >>>>>
> >>>>> GEODE-6391 - Event IDs must be included in the PartitioneRegion
> >>> messages
> >>>>> GEODE-6404 - review use of computeIfAbsent across the code base
> >>>>>
> >>>>>
> >>>>> (experimental and dropped)
> >>>>>
> >>>>> GEODE-6393 - Replace synchronization lock with AtomicReference for
> >>>>> InternalLocator
> >>>>>
> >>>>>
> >>>>> -
> >>>>>
> >>>>> Sai
> >>>>>
> >>>>> On Thu, Feb 14, 2019 at 3:21 PM Sai Boorlagadda <
> >>>> sai.boorlagadda@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>>> I didn't mean blocking a release but the release process (including
> >>>>>> cutting the branch).
> >>>>>>
> >>>>>>
> >>>>>> I thought there was a consensus about strictly cutting a
> >>>>>>
> >>>>>> branch[1] with our new fixed minor release cadence and
> >>>>>>
> >>>>>> only allow critical fixes.
> >>>>>>
> >>>>>>
> >>>>>> I assumed that any critical fixes that are allowed onto the
> >>>>>>
> >>>>>> release branch are the ones that are identified on the branch
> >>>>>>
> >>>>>> after it is cut and not the ones that are already known.
> >>>>>>
> >>>>>>
> >>>>>> Correct me if my understanding is wrong.
> >>>>>>
> >>>>>>
> >>>>>> [1]
> >>>>>>
> >>>
> https://lists.apache.org/thread.html/d36a63c3794d13506ecad3d52a2aca938dcf0f8509b61860bbbc50cd@%3Cdev.geode.apache.org%3E
> >>>>>> On Thu, Feb 14, 2019 at 12:00 PM Nabarun Nag <nn...@pivotal.io>
> >>> wrote:
> >>>>>>> I could not find any DISCUSS mails about not blocking a release. I
> >>> may
> >>>> be
> >>>>>>> wrong, I apologize for that but could point me to the mail /
> >>>> documentation
> >>>>>>> about the release management.
> >>>>>>>
> >>>>>>> Regards
> >>>>>>> Naba
> >>>>>>>
> >>>>>>> On Thu, Feb 14, 2019 at 11:52 AM Sai Boorlagadda <
> >>>>>>> sai.boorlagadda@gmail.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> Did we not agreed that we won't be blocking a release to include
> >>> fixes
> >>>>>>> as
> >>>>>>>> we are in a fixed release schedule?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Thu, Feb 14, 2019 at 11:36 AM Alexander Murmann <
> >>>> amurmann@apache.org
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> Usually I am a proponent of cutting a branch and then fixing
> >>> things
> >>>> on
> >>>>>>>>> there where things are more stable. In this case we seem to have
> a
> >>>>>>> large
> >>>>>>>>> number of fairly serious concerns. Do we think the cost of
> putting
> >>>>>>> this
> >>>>>>>>> many fixes on develop + the release branch out-weights the
> >>> benefit of
> >>>>>>>> less
> >>>>>>>>> risk of new issues being introduced?
> >>>>>>>>>
> >>>>>>>>> Thoughts?
> >>>>>>>>>
> >>>>>>>>> Thank you, Sai for taking over!
> >>>>>>>>>
> >>>>>>>>> On Thu, Feb 14, 2019 at 10:32 AM Sai Boorlagadda <
> >>>>>>>>> sai.boorlagadda@gmail.com>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> I volunteer to be the release manager for 1.9.
> >>>>>>>>>>
> >>>>>>>>>> Sai
> >>>>>>>>>>
> >>>>>>>>>> On Wed, Feb 13, 2019 at 7:48 PM Alexander Murmann <
> >>>>>>> amurmann@apache.org
> >>>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> If there are no other takers, I can act as release manager for
> >>> 1.9
> >>>>>>>> and
> >>>>>>>>>> will
> >>>>>>>>>>> cut a release branch this week.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On Tue, Jan 29, 2019 at 1:50 PM Alexander Murmann <
> >>>>>>>> amurmann@apache.org
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Hi everyone!
> >>>>>>>>>>>>
> >>>>>>>>>>>> February 1st is approaching rapidly which means it's almost
> >>>>>>> time to
> >>>>>>>>> cut
> >>>>>>>>>>>> the 1.9 release. Who is interested in being the release
> manager
> >>>>>>> for
> >>>>>>>>>> 1.9?
> >>>>>>>>>>>> Thank you!
> >>>>>>>>>>>>
>
Re: Geode 1.9 Release Manager
Posted by Bruce Schuchardt <bs...@pivotal.io>.
The fix for Geode-6369 has been pushed to develop. This needs to go in
the 1.9 release as it fixes some serious issues in auto-reconnect
including a distributed deadlock.
On 2/15/19 2:15 PM, Sai Boorlagadda wrote:
> There are about 8[1] issues in JIRA that are in open/in-progress/re-opened
> status for 1.9.0.
> Can I request all the devs to reflect JIRA with current status?
>
> [1]
> https://issues.apache.org/jira/browse/GEODE-6107?jql=project%20%3D%20GEODE%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20fixVersion%20%3D%201.9.0
>
> Sai
>
> On Fri, Feb 15, 2019 at 12:56 PM Sai Boorlagadda <sa...@gmail.com>
> wrote:
>
>> Thanks Dave. I keep a note to include Geode Native.
>>
>> As we are including only a source release for Geode Native
>> do we need to create a release branch? Or just tag it?
>>
>> Though we will eventually be tagging Geode & Geode Examples repos.
>> So until it gets released I think as a place holder I can go ahead still
>> create a release branch for Geode Native?
>>
>> Sai
>>
>>
>> On Fri, Feb 15, 2019 at 9:51 AM Dave Barnes <db...@apache.org> wrote:
>>
>>> Sai,
>>> The Geode 1.8 release included (for the first time) a source snapshot of
>>> the geode-native repo.
>>> As far as I know, the same treatment would be in order for v1.9.
>>>
>>>
>>> On Fri, Feb 15, 2019 at 9:01 AM Bruce Schuchardt <bs...@pivotal.io>
>>> wrote:
>>>
>>>> I would like to get GEODE-6369 into the next release but that can be
>>>> done in a cherry-pick after I finish testing. The changes are in in
>>>> discovery, joining the cluster and in failure detection so they've
>>>> needed extensive testing.
>>>>
>>>> On 2/15/19 7:53 AM, Sai Boorlagadda wrote:
>>>>> I am planning to cut the1.9 release branch today after merging this
>>>>> PR #3195 which is reverting changes to GEODE-6334 & GEODE-6345.
>>>>>
>>>>> Is there anything other than that I should be aware of?
>>>>>
>>>>> Here is the list of issues that were requested to be included into
>>> 1.9.
>>>>> If there is any plan to merge any of these today let me know and
>>>>> I can cut the branch after that.
>>>>>
>>>>> GEODE-6334 - CachePerfStats operation count stats may wrap to negative
>>>>> values
>>>>>
>>>>> GEODE-6345 - StatSamplerStats jvmPauses stat may wrap to negative
>>> value
>>>>> GEODE-6369 - Cache-creation failure after a successful auto-reconnect
>>>>> causes subsequent NPE
>>>>>
>>>>> GEODE-6391 - Event IDs must be included in the PartitioneRegion
>>> messages
>>>>> GEODE-6404 - review use of computeIfAbsent across the code base
>>>>>
>>>>>
>>>>> (experimental and dropped)
>>>>>
>>>>> GEODE-6393 - Replace synchronization lock with AtomicReference for
>>>>> InternalLocator
>>>>>
>>>>>
>>>>> -
>>>>>
>>>>> Sai
>>>>>
>>>>> On Thu, Feb 14, 2019 at 3:21 PM Sai Boorlagadda <
>>>> sai.boorlagadda@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> I didn't mean blocking a release but the release process (including
>>>>>> cutting the branch).
>>>>>>
>>>>>>
>>>>>> I thought there was a consensus about strictly cutting a
>>>>>>
>>>>>> branch[1] with our new fixed minor release cadence and
>>>>>>
>>>>>> only allow critical fixes.
>>>>>>
>>>>>>
>>>>>> I assumed that any critical fixes that are allowed onto the
>>>>>>
>>>>>> release branch are the ones that are identified on the branch
>>>>>>
>>>>>> after it is cut and not the ones that are already known.
>>>>>>
>>>>>>
>>>>>> Correct me if my understanding is wrong.
>>>>>>
>>>>>>
>>>>>> [1]
>>>>>>
>>> https://lists.apache.org/thread.html/d36a63c3794d13506ecad3d52a2aca938dcf0f8509b61860bbbc50cd@%3Cdev.geode.apache.org%3E
>>>>>> On Thu, Feb 14, 2019 at 12:00 PM Nabarun Nag <nn...@pivotal.io>
>>> wrote:
>>>>>>> I could not find any DISCUSS mails about not blocking a release. I
>>> may
>>>> be
>>>>>>> wrong, I apologize for that but could point me to the mail /
>>>> documentation
>>>>>>> about the release management.
>>>>>>>
>>>>>>> Regards
>>>>>>> Naba
>>>>>>>
>>>>>>> On Thu, Feb 14, 2019 at 11:52 AM Sai Boorlagadda <
>>>>>>> sai.boorlagadda@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Did we not agreed that we won't be blocking a release to include
>>> fixes
>>>>>>> as
>>>>>>>> we are in a fixed release schedule?
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Feb 14, 2019 at 11:36 AM Alexander Murmann <
>>>> amurmann@apache.org
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Usually I am a proponent of cutting a branch and then fixing
>>> things
>>>> on
>>>>>>>>> there where things are more stable. In this case we seem to have a
>>>>>>> large
>>>>>>>>> number of fairly serious concerns. Do we think the cost of putting
>>>>>>> this
>>>>>>>>> many fixes on develop + the release branch out-weights the
>>> benefit of
>>>>>>>> less
>>>>>>>>> risk of new issues being introduced?
>>>>>>>>>
>>>>>>>>> Thoughts?
>>>>>>>>>
>>>>>>>>> Thank you, Sai for taking over!
>>>>>>>>>
>>>>>>>>> On Thu, Feb 14, 2019 at 10:32 AM Sai Boorlagadda <
>>>>>>>>> sai.boorlagadda@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> I volunteer to be the release manager for 1.9.
>>>>>>>>>>
>>>>>>>>>> Sai
>>>>>>>>>>
>>>>>>>>>> On Wed, Feb 13, 2019 at 7:48 PM Alexander Murmann <
>>>>>>> amurmann@apache.org
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> If there are no other takers, I can act as release manager for
>>> 1.9
>>>>>>>> and
>>>>>>>>>> will
>>>>>>>>>>> cut a release branch this week.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Jan 29, 2019 at 1:50 PM Alexander Murmann <
>>>>>>>> amurmann@apache.org
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi everyone!
>>>>>>>>>>>>
>>>>>>>>>>>> February 1st is approaching rapidly which means it's almost
>>>>>>> time to
>>>>>>>>> cut
>>>>>>>>>>>> the 1.9 release. Who is interested in being the release manager
>>>>>>> for
>>>>>>>>>> 1.9?
>>>>>>>>>>>> Thank you!
>>>>>>>>>>>>
Re: Geode 1.9 Release Manager
Posted by Sai Boorlagadda <sa...@gmail.com>.
There are about 8[1] issues in JIRA that are in open/in-progress/re-opened
status for 1.9.0.
Can I request all the devs to reflect JIRA with current status?
[1]
https://issues.apache.org/jira/browse/GEODE-6107?jql=project%20%3D%20GEODE%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20fixVersion%20%3D%201.9.0
Sai
On Fri, Feb 15, 2019 at 12:56 PM Sai Boorlagadda <sa...@gmail.com>
wrote:
> Thanks Dave. I keep a note to include Geode Native.
>
> As we are including only a source release for Geode Native
> do we need to create a release branch? Or just tag it?
>
> Though we will eventually be tagging Geode & Geode Examples repos.
> So until it gets released I think as a place holder I can go ahead still
> create a release branch for Geode Native?
>
> Sai
>
>
> On Fri, Feb 15, 2019 at 9:51 AM Dave Barnes <db...@apache.org> wrote:
>
>> Sai,
>> The Geode 1.8 release included (for the first time) a source snapshot of
>> the geode-native repo.
>> As far as I know, the same treatment would be in order for v1.9.
>>
>>
>> On Fri, Feb 15, 2019 at 9:01 AM Bruce Schuchardt <bs...@pivotal.io>
>> wrote:
>>
>> > I would like to get GEODE-6369 into the next release but that can be
>> > done in a cherry-pick after I finish testing. The changes are in in
>> > discovery, joining the cluster and in failure detection so they've
>> > needed extensive testing.
>> >
>> > On 2/15/19 7:53 AM, Sai Boorlagadda wrote:
>> > > I am planning to cut the1.9 release branch today after merging this
>> > > PR #3195 which is reverting changes to GEODE-6334 & GEODE-6345.
>> > >
>> > > Is there anything other than that I should be aware of?
>> > >
>> > > Here is the list of issues that were requested to be included into
>> 1.9.
>> > > If there is any plan to merge any of these today let me know and
>> > > I can cut the branch after that.
>> > >
>> > > GEODE-6334 - CachePerfStats operation count stats may wrap to negative
>> > > values
>> > >
>> > > GEODE-6345 - StatSamplerStats jvmPauses stat may wrap to negative
>> value
>> > >
>> > > GEODE-6369 - Cache-creation failure after a successful auto-reconnect
>> > > causes subsequent NPE
>> > >
>> > > GEODE-6391 - Event IDs must be included in the PartitioneRegion
>> messages
>> > >
>> > > GEODE-6404 - review use of computeIfAbsent across the code base
>> > >
>> > >
>> > > (experimental and dropped)
>> > >
>> > > GEODE-6393 - Replace synchronization lock with AtomicReference for
>> > > InternalLocator
>> > >
>> > >
>> > > -
>> > >
>> > > Sai
>> > >
>> > > On Thu, Feb 14, 2019 at 3:21 PM Sai Boorlagadda <
>> > sai.boorlagadda@gmail.com>
>> > > wrote:
>> > >
>> > >> I didn't mean blocking a release but the release process (including
>> > >> cutting the branch).
>> > >>
>> > >>
>> > >> I thought there was a consensus about strictly cutting a
>> > >>
>> > >> branch[1] with our new fixed minor release cadence and
>> > >>
>> > >> only allow critical fixes.
>> > >>
>> > >>
>> > >> I assumed that any critical fixes that are allowed onto the
>> > >>
>> > >> release branch are the ones that are identified on the branch
>> > >>
>> > >> after it is cut and not the ones that are already known.
>> > >>
>> > >>
>> > >> Correct me if my understanding is wrong.
>> > >>
>> > >>
>> > >> [1]
>> > >>
>> >
>> https://lists.apache.org/thread.html/d36a63c3794d13506ecad3d52a2aca938dcf0f8509b61860bbbc50cd@%3Cdev.geode.apache.org%3E
>> > >>
>> > >> On Thu, Feb 14, 2019 at 12:00 PM Nabarun Nag <nn...@pivotal.io>
>> wrote:
>> > >>
>> > >>> I could not find any DISCUSS mails about not blocking a release. I
>> may
>> > be
>> > >>> wrong, I apologize for that but could point me to the mail /
>> > documentation
>> > >>> about the release management.
>> > >>>
>> > >>> Regards
>> > >>> Naba
>> > >>>
>> > >>> On Thu, Feb 14, 2019 at 11:52 AM Sai Boorlagadda <
>> > >>> sai.boorlagadda@gmail.com>
>> > >>> wrote:
>> > >>>
>> > >>>> Did we not agreed that we won't be blocking a release to include
>> fixes
>> > >>> as
>> > >>>> we are in a fixed release schedule?
>> > >>>>
>> > >>>>
>> > >>>> On Thu, Feb 14, 2019 at 11:36 AM Alexander Murmann <
>> > amurmann@apache.org
>> > >>>>
>> > >>>> wrote:
>> > >>>>
>> > >>>>> Usually I am a proponent of cutting a branch and then fixing
>> things
>> > on
>> > >>>>> there where things are more stable. In this case we seem to have a
>> > >>> large
>> > >>>>> number of fairly serious concerns. Do we think the cost of putting
>> > >>> this
>> > >>>>> many fixes on develop + the release branch out-weights the
>> benefit of
>> > >>>> less
>> > >>>>> risk of new issues being introduced?
>> > >>>>>
>> > >>>>> Thoughts?
>> > >>>>>
>> > >>>>> Thank you, Sai for taking over!
>> > >>>>>
>> > >>>>> On Thu, Feb 14, 2019 at 10:32 AM Sai Boorlagadda <
>> > >>>>> sai.boorlagadda@gmail.com>
>> > >>>>> wrote:
>> > >>>>>
>> > >>>>>> I volunteer to be the release manager for 1.9.
>> > >>>>>>
>> > >>>>>> Sai
>> > >>>>>>
>> > >>>>>> On Wed, Feb 13, 2019 at 7:48 PM Alexander Murmann <
>> > >>> amurmann@apache.org
>> > >>>>>> wrote:
>> > >>>>>>
>> > >>>>>>> If there are no other takers, I can act as release manager for
>> 1.9
>> > >>>> and
>> > >>>>>> will
>> > >>>>>>> cut a release branch this week.
>> > >>>>>>>
>> > >>>>>>>
>> > >>>>>>> On Tue, Jan 29, 2019 at 1:50 PM Alexander Murmann <
>> > >>>> amurmann@apache.org
>> > >>>>>>> wrote:
>> > >>>>>>>
>> > >>>>>>>> Hi everyone!
>> > >>>>>>>>
>> > >>>>>>>> February 1st is approaching rapidly which means it's almost
>> > >>> time to
>> > >>>>> cut
>> > >>>>>>>> the 1.9 release. Who is interested in being the release manager
>> > >>> for
>> > >>>>>> 1.9?
>> > >>>>>>>> Thank you!
>> > >>>>>>>>
>> >
>>
>
Re: Geode 1.9 Release Manager
Posted by Sai Boorlagadda <sa...@gmail.com>.
Thanks Dave. I keep a note to include Geode Native.
As we are including only a source release for Geode Native
do we need to create a release branch? Or just tag it?
Though we will eventually be tagging Geode & Geode Examples repos.
So until it gets released I think as a place holder I can go ahead still
create a release branch for Geode Native?
Sai
On Fri, Feb 15, 2019 at 9:51 AM Dave Barnes <db...@apache.org> wrote:
> Sai,
> The Geode 1.8 release included (for the first time) a source snapshot of
> the geode-native repo.
> As far as I know, the same treatment would be in order for v1.9.
>
>
> On Fri, Feb 15, 2019 at 9:01 AM Bruce Schuchardt <bs...@pivotal.io>
> wrote:
>
> > I would like to get GEODE-6369 into the next release but that can be
> > done in a cherry-pick after I finish testing. The changes are in in
> > discovery, joining the cluster and in failure detection so they've
> > needed extensive testing.
> >
> > On 2/15/19 7:53 AM, Sai Boorlagadda wrote:
> > > I am planning to cut the1.9 release branch today after merging this
> > > PR #3195 which is reverting changes to GEODE-6334 & GEODE-6345.
> > >
> > > Is there anything other than that I should be aware of?
> > >
> > > Here is the list of issues that were requested to be included into 1.9.
> > > If there is any plan to merge any of these today let me know and
> > > I can cut the branch after that.
> > >
> > > GEODE-6334 - CachePerfStats operation count stats may wrap to negative
> > > values
> > >
> > > GEODE-6345 - StatSamplerStats jvmPauses stat may wrap to negative value
> > >
> > > GEODE-6369 - Cache-creation failure after a successful auto-reconnect
> > > causes subsequent NPE
> > >
> > > GEODE-6391 - Event IDs must be included in the PartitioneRegion
> messages
> > >
> > > GEODE-6404 - review use of computeIfAbsent across the code base
> > >
> > >
> > > (experimental and dropped)
> > >
> > > GEODE-6393 - Replace synchronization lock with AtomicReference for
> > > InternalLocator
> > >
> > >
> > > -
> > >
> > > Sai
> > >
> > > On Thu, Feb 14, 2019 at 3:21 PM Sai Boorlagadda <
> > sai.boorlagadda@gmail.com>
> > > wrote:
> > >
> > >> I didn't mean blocking a release but the release process (including
> > >> cutting the branch).
> > >>
> > >>
> > >> I thought there was a consensus about strictly cutting a
> > >>
> > >> branch[1] with our new fixed minor release cadence and
> > >>
> > >> only allow critical fixes.
> > >>
> > >>
> > >> I assumed that any critical fixes that are allowed onto the
> > >>
> > >> release branch are the ones that are identified on the branch
> > >>
> > >> after it is cut and not the ones that are already known.
> > >>
> > >>
> > >> Correct me if my understanding is wrong.
> > >>
> > >>
> > >> [1]
> > >>
> >
> https://lists.apache.org/thread.html/d36a63c3794d13506ecad3d52a2aca938dcf0f8509b61860bbbc50cd@%3Cdev.geode.apache.org%3E
> > >>
> > >> On Thu, Feb 14, 2019 at 12:00 PM Nabarun Nag <nn...@pivotal.io> wrote:
> > >>
> > >>> I could not find any DISCUSS mails about not blocking a release. I
> may
> > be
> > >>> wrong, I apologize for that but could point me to the mail /
> > documentation
> > >>> about the release management.
> > >>>
> > >>> Regards
> > >>> Naba
> > >>>
> > >>> On Thu, Feb 14, 2019 at 11:52 AM Sai Boorlagadda <
> > >>> sai.boorlagadda@gmail.com>
> > >>> wrote:
> > >>>
> > >>>> Did we not agreed that we won't be blocking a release to include
> fixes
> > >>> as
> > >>>> we are in a fixed release schedule?
> > >>>>
> > >>>>
> > >>>> On Thu, Feb 14, 2019 at 11:36 AM Alexander Murmann <
> > amurmann@apache.org
> > >>>>
> > >>>> wrote:
> > >>>>
> > >>>>> Usually I am a proponent of cutting a branch and then fixing things
> > on
> > >>>>> there where things are more stable. In this case we seem to have a
> > >>> large
> > >>>>> number of fairly serious concerns. Do we think the cost of putting
> > >>> this
> > >>>>> many fixes on develop + the release branch out-weights the benefit
> of
> > >>>> less
> > >>>>> risk of new issues being introduced?
> > >>>>>
> > >>>>> Thoughts?
> > >>>>>
> > >>>>> Thank you, Sai for taking over!
> > >>>>>
> > >>>>> On Thu, Feb 14, 2019 at 10:32 AM Sai Boorlagadda <
> > >>>>> sai.boorlagadda@gmail.com>
> > >>>>> wrote:
> > >>>>>
> > >>>>>> I volunteer to be the release manager for 1.9.
> > >>>>>>
> > >>>>>> Sai
> > >>>>>>
> > >>>>>> On Wed, Feb 13, 2019 at 7:48 PM Alexander Murmann <
> > >>> amurmann@apache.org
> > >>>>>> wrote:
> > >>>>>>
> > >>>>>>> If there are no other takers, I can act as release manager for
> 1.9
> > >>>> and
> > >>>>>> will
> > >>>>>>> cut a release branch this week.
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> On Tue, Jan 29, 2019 at 1:50 PM Alexander Murmann <
> > >>>> amurmann@apache.org
> > >>>>>>> wrote:
> > >>>>>>>
> > >>>>>>>> Hi everyone!
> > >>>>>>>>
> > >>>>>>>> February 1st is approaching rapidly which means it's almost
> > >>> time to
> > >>>>> cut
> > >>>>>>>> the 1.9 release. Who is interested in being the release manager
> > >>> for
> > >>>>>> 1.9?
> > >>>>>>>> Thank you!
> > >>>>>>>>
> >
>
Re: Geode 1.9 Release Manager
Posted by Dave Barnes <db...@apache.org>.
Sai,
The Geode 1.8 release included (for the first time) a source snapshot of
the geode-native repo.
As far as I know, the same treatment would be in order for v1.9.
On Fri, Feb 15, 2019 at 9:01 AM Bruce Schuchardt <bs...@pivotal.io>
wrote:
> I would like to get GEODE-6369 into the next release but that can be
> done in a cherry-pick after I finish testing. The changes are in in
> discovery, joining the cluster and in failure detection so they've
> needed extensive testing.
>
> On 2/15/19 7:53 AM, Sai Boorlagadda wrote:
> > I am planning to cut the1.9 release branch today after merging this
> > PR #3195 which is reverting changes to GEODE-6334 & GEODE-6345.
> >
> > Is there anything other than that I should be aware of?
> >
> > Here is the list of issues that were requested to be included into 1.9.
> > If there is any plan to merge any of these today let me know and
> > I can cut the branch after that.
> >
> > GEODE-6334 - CachePerfStats operation count stats may wrap to negative
> > values
> >
> > GEODE-6345 - StatSamplerStats jvmPauses stat may wrap to negative value
> >
> > GEODE-6369 - Cache-creation failure after a successful auto-reconnect
> > causes subsequent NPE
> >
> > GEODE-6391 - Event IDs must be included in the PartitioneRegion messages
> >
> > GEODE-6404 - review use of computeIfAbsent across the code base
> >
> >
> > (experimental and dropped)
> >
> > GEODE-6393 - Replace synchronization lock with AtomicReference for
> > InternalLocator
> >
> >
> > -
> >
> > Sai
> >
> > On Thu, Feb 14, 2019 at 3:21 PM Sai Boorlagadda <
> sai.boorlagadda@gmail.com>
> > wrote:
> >
> >> I didn't mean blocking a release but the release process (including
> >> cutting the branch).
> >>
> >>
> >> I thought there was a consensus about strictly cutting a
> >>
> >> branch[1] with our new fixed minor release cadence and
> >>
> >> only allow critical fixes.
> >>
> >>
> >> I assumed that any critical fixes that are allowed onto the
> >>
> >> release branch are the ones that are identified on the branch
> >>
> >> after it is cut and not the ones that are already known.
> >>
> >>
> >> Correct me if my understanding is wrong.
> >>
> >>
> >> [1]
> >>
> https://lists.apache.org/thread.html/d36a63c3794d13506ecad3d52a2aca938dcf0f8509b61860bbbc50cd@%3Cdev.geode.apache.org%3E
> >>
> >> On Thu, Feb 14, 2019 at 12:00 PM Nabarun Nag <nn...@pivotal.io> wrote:
> >>
> >>> I could not find any DISCUSS mails about not blocking a release. I may
> be
> >>> wrong, I apologize for that but could point me to the mail /
> documentation
> >>> about the release management.
> >>>
> >>> Regards
> >>> Naba
> >>>
> >>> On Thu, Feb 14, 2019 at 11:52 AM Sai Boorlagadda <
> >>> sai.boorlagadda@gmail.com>
> >>> wrote:
> >>>
> >>>> Did we not agreed that we won't be blocking a release to include fixes
> >>> as
> >>>> we are in a fixed release schedule?
> >>>>
> >>>>
> >>>> On Thu, Feb 14, 2019 at 11:36 AM Alexander Murmann <
> amurmann@apache.org
> >>>>
> >>>> wrote:
> >>>>
> >>>>> Usually I am a proponent of cutting a branch and then fixing things
> on
> >>>>> there where things are more stable. In this case we seem to have a
> >>> large
> >>>>> number of fairly serious concerns. Do we think the cost of putting
> >>> this
> >>>>> many fixes on develop + the release branch out-weights the benefit of
> >>>> less
> >>>>> risk of new issues being introduced?
> >>>>>
> >>>>> Thoughts?
> >>>>>
> >>>>> Thank you, Sai for taking over!
> >>>>>
> >>>>> On Thu, Feb 14, 2019 at 10:32 AM Sai Boorlagadda <
> >>>>> sai.boorlagadda@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>>> I volunteer to be the release manager for 1.9.
> >>>>>>
> >>>>>> Sai
> >>>>>>
> >>>>>> On Wed, Feb 13, 2019 at 7:48 PM Alexander Murmann <
> >>> amurmann@apache.org
> >>>>>> wrote:
> >>>>>>
> >>>>>>> If there are no other takers, I can act as release manager for 1.9
> >>>> and
> >>>>>> will
> >>>>>>> cut a release branch this week.
> >>>>>>>
> >>>>>>>
> >>>>>>> On Tue, Jan 29, 2019 at 1:50 PM Alexander Murmann <
> >>>> amurmann@apache.org
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> Hi everyone!
> >>>>>>>>
> >>>>>>>> February 1st is approaching rapidly which means it's almost
> >>> time to
> >>>>> cut
> >>>>>>>> the 1.9 release. Who is interested in being the release manager
> >>> for
> >>>>>> 1.9?
> >>>>>>>> Thank you!
> >>>>>>>>
>
Re: Geode 1.9 Release Manager
Posted by Bruce Schuchardt <bs...@pivotal.io>.
I would like to get GEODE-6369 into the next release but that can be
done in a cherry-pick after I finish testing. The changes are in in
discovery, joining the cluster and in failure detection so they've
needed extensive testing.
On 2/15/19 7:53 AM, Sai Boorlagadda wrote:
> I am planning to cut the1.9 release branch today after merging this
> PR #3195 which is reverting changes to GEODE-6334 & GEODE-6345.
>
> Is there anything other than that I should be aware of?
>
> Here is the list of issues that were requested to be included into 1.9.
> If there is any plan to merge any of these today let me know and
> I can cut the branch after that.
>
> GEODE-6334 - CachePerfStats operation count stats may wrap to negative
> values
>
> GEODE-6345 - StatSamplerStats jvmPauses stat may wrap to negative value
>
> GEODE-6369 - Cache-creation failure after a successful auto-reconnect
> causes subsequent NPE
>
> GEODE-6391 - Event IDs must be included in the PartitioneRegion messages
>
> GEODE-6404 - review use of computeIfAbsent across the code base
>
>
> (experimental and dropped)
>
> GEODE-6393 - Replace synchronization lock with AtomicReference for
> InternalLocator
>
>
> -
>
> Sai
>
> On Thu, Feb 14, 2019 at 3:21 PM Sai Boorlagadda <sa...@gmail.com>
> wrote:
>
>> I didn't mean blocking a release but the release process (including
>> cutting the branch).
>>
>>
>> I thought there was a consensus about strictly cutting a
>>
>> branch[1] with our new fixed minor release cadence and
>>
>> only allow critical fixes.
>>
>>
>> I assumed that any critical fixes that are allowed onto the
>>
>> release branch are the ones that are identified on the branch
>>
>> after it is cut and not the ones that are already known.
>>
>>
>> Correct me if my understanding is wrong.
>>
>>
>> [1]
>> https://lists.apache.org/thread.html/d36a63c3794d13506ecad3d52a2aca938dcf0f8509b61860bbbc50cd@%3Cdev.geode.apache.org%3E
>>
>> On Thu, Feb 14, 2019 at 12:00 PM Nabarun Nag <nn...@pivotal.io> wrote:
>>
>>> I could not find any DISCUSS mails about not blocking a release. I may be
>>> wrong, I apologize for that but could point me to the mail / documentation
>>> about the release management.
>>>
>>> Regards
>>> Naba
>>>
>>> On Thu, Feb 14, 2019 at 11:52 AM Sai Boorlagadda <
>>> sai.boorlagadda@gmail.com>
>>> wrote:
>>>
>>>> Did we not agreed that we won't be blocking a release to include fixes
>>> as
>>>> we are in a fixed release schedule?
>>>>
>>>>
>>>> On Thu, Feb 14, 2019 at 11:36 AM Alexander Murmann <amurmann@apache.org
>>>>
>>>> wrote:
>>>>
>>>>> Usually I am a proponent of cutting a branch and then fixing things on
>>>>> there where things are more stable. In this case we seem to have a
>>> large
>>>>> number of fairly serious concerns. Do we think the cost of putting
>>> this
>>>>> many fixes on develop + the release branch out-weights the benefit of
>>>> less
>>>>> risk of new issues being introduced?
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> Thank you, Sai for taking over!
>>>>>
>>>>> On Thu, Feb 14, 2019 at 10:32 AM Sai Boorlagadda <
>>>>> sai.boorlagadda@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> I volunteer to be the release manager for 1.9.
>>>>>>
>>>>>> Sai
>>>>>>
>>>>>> On Wed, Feb 13, 2019 at 7:48 PM Alexander Murmann <
>>> amurmann@apache.org
>>>>>> wrote:
>>>>>>
>>>>>>> If there are no other takers, I can act as release manager for 1.9
>>>> and
>>>>>> will
>>>>>>> cut a release branch this week.
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jan 29, 2019 at 1:50 PM Alexander Murmann <
>>>> amurmann@apache.org
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi everyone!
>>>>>>>>
>>>>>>>> February 1st is approaching rapidly which means it's almost
>>> time to
>>>>> cut
>>>>>>>> the 1.9 release. Who is interested in being the release manager
>>> for
>>>>>> 1.9?
>>>>>>>> Thank you!
>>>>>>>>
Re: Geode 1.9 Release Manager
Posted by Sai Boorlagadda <sa...@gmail.com>.
I am planning to cut the1.9 release branch today after merging this
PR #3195 which is reverting changes to GEODE-6334 & GEODE-6345.
Is there anything other than that I should be aware of?
Here is the list of issues that were requested to be included into 1.9.
If there is any plan to merge any of these today let me know and
I can cut the branch after that.
GEODE-6334 - CachePerfStats operation count stats may wrap to negative
values
GEODE-6345 - StatSamplerStats jvmPauses stat may wrap to negative value
GEODE-6369 - Cache-creation failure after a successful auto-reconnect
causes subsequent NPE
GEODE-6391 - Event IDs must be included in the PartitioneRegion messages
GEODE-6404 - review use of computeIfAbsent across the code base
(experimental and dropped)
GEODE-6393 - Replace synchronization lock with AtomicReference for
InternalLocator
-
Sai
On Thu, Feb 14, 2019 at 3:21 PM Sai Boorlagadda <sa...@gmail.com>
wrote:
> I didn't mean blocking a release but the release process (including
> cutting the branch).
>
>
> I thought there was a consensus about strictly cutting a
>
> branch[1] with our new fixed minor release cadence and
>
> only allow critical fixes.
>
>
> I assumed that any critical fixes that are allowed onto the
>
> release branch are the ones that are identified on the branch
>
> after it is cut and not the ones that are already known.
>
>
> Correct me if my understanding is wrong.
>
>
> [1]
> https://lists.apache.org/thread.html/d36a63c3794d13506ecad3d52a2aca938dcf0f8509b61860bbbc50cd@%3Cdev.geode.apache.org%3E
>
> On Thu, Feb 14, 2019 at 12:00 PM Nabarun Nag <nn...@pivotal.io> wrote:
>
>> I could not find any DISCUSS mails about not blocking a release. I may be
>> wrong, I apologize for that but could point me to the mail / documentation
>> about the release management.
>>
>> Regards
>> Naba
>>
>> On Thu, Feb 14, 2019 at 11:52 AM Sai Boorlagadda <
>> sai.boorlagadda@gmail.com>
>> wrote:
>>
>> > Did we not agreed that we won't be blocking a release to include fixes
>> as
>> > we are in a fixed release schedule?
>> >
>> >
>> > On Thu, Feb 14, 2019 at 11:36 AM Alexander Murmann <amurmann@apache.org
>> >
>> > wrote:
>> >
>> > > Usually I am a proponent of cutting a branch and then fixing things on
>> > > there where things are more stable. In this case we seem to have a
>> large
>> > > number of fairly serious concerns. Do we think the cost of putting
>> this
>> > > many fixes on develop + the release branch out-weights the benefit of
>> > less
>> > > risk of new issues being introduced?
>> > >
>> > > Thoughts?
>> > >
>> > > Thank you, Sai for taking over!
>> > >
>> > > On Thu, Feb 14, 2019 at 10:32 AM Sai Boorlagadda <
>> > > sai.boorlagadda@gmail.com>
>> > > wrote:
>> > >
>> > > > I volunteer to be the release manager for 1.9.
>> > > >
>> > > > Sai
>> > > >
>> > > > On Wed, Feb 13, 2019 at 7:48 PM Alexander Murmann <
>> amurmann@apache.org
>> > >
>> > > > wrote:
>> > > >
>> > > > > If there are no other takers, I can act as release manager for 1.9
>> > and
>> > > > will
>> > > > > cut a release branch this week.
>> > > > >
>> > > > >
>> > > > > On Tue, Jan 29, 2019 at 1:50 PM Alexander Murmann <
>> > amurmann@apache.org
>> > > >
>> > > > > wrote:
>> > > > >
>> > > > > > Hi everyone!
>> > > > > >
>> > > > > > February 1st is approaching rapidly which means it's almost
>> time to
>> > > cut
>> > > > > > the 1.9 release. Who is interested in being the release manager
>> for
>> > > > 1.9?
>> > > > > >
>> > > > > > Thank you!
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
Re: Geode 1.9 Release Manager
Posted by Sai Boorlagadda <sa...@gmail.com>.
I didn't mean blocking a release but the release process (including cutting
the branch).
I thought there was a consensus about strictly cutting a
branch[1] with our new fixed minor release cadence and
only allow critical fixes.
I assumed that any critical fixes that are allowed onto the
release branch are the ones that are identified on the branch
after it is cut and not the ones that are already known.
Correct me if my understanding is wrong.
[1]
https://lists.apache.org/thread.html/d36a63c3794d13506ecad3d52a2aca938dcf0f8509b61860bbbc50cd@%3Cdev.geode.apache.org%3E
On Thu, Feb 14, 2019 at 12:00 PM Nabarun Nag <nn...@pivotal.io> wrote:
> I could not find any DISCUSS mails about not blocking a release. I may be
> wrong, I apologize for that but could point me to the mail / documentation
> about the release management.
>
> Regards
> Naba
>
> On Thu, Feb 14, 2019 at 11:52 AM Sai Boorlagadda <
> sai.boorlagadda@gmail.com>
> wrote:
>
> > Did we not agreed that we won't be blocking a release to include fixes as
> > we are in a fixed release schedule?
> >
> >
> > On Thu, Feb 14, 2019 at 11:36 AM Alexander Murmann <am...@apache.org>
> > wrote:
> >
> > > Usually I am a proponent of cutting a branch and then fixing things on
> > > there where things are more stable. In this case we seem to have a
> large
> > > number of fairly serious concerns. Do we think the cost of putting this
> > > many fixes on develop + the release branch out-weights the benefit of
> > less
> > > risk of new issues being introduced?
> > >
> > > Thoughts?
> > >
> > > Thank you, Sai for taking over!
> > >
> > > On Thu, Feb 14, 2019 at 10:32 AM Sai Boorlagadda <
> > > sai.boorlagadda@gmail.com>
> > > wrote:
> > >
> > > > I volunteer to be the release manager for 1.9.
> > > >
> > > > Sai
> > > >
> > > > On Wed, Feb 13, 2019 at 7:48 PM Alexander Murmann <
> amurmann@apache.org
> > >
> > > > wrote:
> > > >
> > > > > If there are no other takers, I can act as release manager for 1.9
> > and
> > > > will
> > > > > cut a release branch this week.
> > > > >
> > > > >
> > > > > On Tue, Jan 29, 2019 at 1:50 PM Alexander Murmann <
> > amurmann@apache.org
> > > >
> > > > > wrote:
> > > > >
> > > > > > Hi everyone!
> > > > > >
> > > > > > February 1st is approaching rapidly which means it's almost time
> to
> > > cut
> > > > > > the 1.9 release. Who is interested in being the release manager
> for
> > > > 1.9?
> > > > > >
> > > > > > Thank you!
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Geode 1.9 Release Manager
Posted by Nabarun Nag <nn...@pivotal.io>.
I could not find any DISCUSS mails about not blocking a release. I may be
wrong, I apologize for that but could point me to the mail / documentation
about the release management.
Regards
Naba
On Thu, Feb 14, 2019 at 11:52 AM Sai Boorlagadda <sa...@gmail.com>
wrote:
> Did we not agreed that we won't be blocking a release to include fixes as
> we are in a fixed release schedule?
>
>
> On Thu, Feb 14, 2019 at 11:36 AM Alexander Murmann <am...@apache.org>
> wrote:
>
> > Usually I am a proponent of cutting a branch and then fixing things on
> > there where things are more stable. In this case we seem to have a large
> > number of fairly serious concerns. Do we think the cost of putting this
> > many fixes on develop + the release branch out-weights the benefit of
> less
> > risk of new issues being introduced?
> >
> > Thoughts?
> >
> > Thank you, Sai for taking over!
> >
> > On Thu, Feb 14, 2019 at 10:32 AM Sai Boorlagadda <
> > sai.boorlagadda@gmail.com>
> > wrote:
> >
> > > I volunteer to be the release manager for 1.9.
> > >
> > > Sai
> > >
> > > On Wed, Feb 13, 2019 at 7:48 PM Alexander Murmann <amurmann@apache.org
> >
> > > wrote:
> > >
> > > > If there are no other takers, I can act as release manager for 1.9
> and
> > > will
> > > > cut a release branch this week.
> > > >
> > > >
> > > > On Tue, Jan 29, 2019 at 1:50 PM Alexander Murmann <
> amurmann@apache.org
> > >
> > > > wrote:
> > > >
> > > > > Hi everyone!
> > > > >
> > > > > February 1st is approaching rapidly which means it's almost time to
> > cut
> > > > > the 1.9 release. Who is interested in being the release manager for
> > > 1.9?
> > > > >
> > > > > Thank you!
> > > > >
> > > >
> > >
> >
>
Re: Geode 1.9 Release Manager
Posted by Sai Boorlagadda <sa...@gmail.com>.
Did we not agreed that we won't be blocking a release to include fixes as
we are in a fixed release schedule?
On Thu, Feb 14, 2019 at 11:36 AM Alexander Murmann <am...@apache.org>
wrote:
> Usually I am a proponent of cutting a branch and then fixing things on
> there where things are more stable. In this case we seem to have a large
> number of fairly serious concerns. Do we think the cost of putting this
> many fixes on develop + the release branch out-weights the benefit of less
> risk of new issues being introduced?
>
> Thoughts?
>
> Thank you, Sai for taking over!
>
> On Thu, Feb 14, 2019 at 10:32 AM Sai Boorlagadda <
> sai.boorlagadda@gmail.com>
> wrote:
>
> > I volunteer to be the release manager for 1.9.
> >
> > Sai
> >
> > On Wed, Feb 13, 2019 at 7:48 PM Alexander Murmann <am...@apache.org>
> > wrote:
> >
> > > If there are no other takers, I can act as release manager for 1.9 and
> > will
> > > cut a release branch this week.
> > >
> > >
> > > On Tue, Jan 29, 2019 at 1:50 PM Alexander Murmann <amurmann@apache.org
> >
> > > wrote:
> > >
> > > > Hi everyone!
> > > >
> > > > February 1st is approaching rapidly which means it's almost time to
> cut
> > > > the 1.9 release. Who is interested in being the release manager for
> > 1.9?
> > > >
> > > > Thank you!
> > > >
> > >
> >
>
Re: Geode 1.9 Release Manager
Posted by Nabarun Nag <nn...@apache.org>.
I agree with the cutting the release branch, keep it sanitized from
additional commits going into develop but ensure only these important
critical fixes mentioned above in this chain makes it into the release
branch.
For the second part, I am not sure how it was determined that fixes for
GEODE-6391, GEODE-6393, GEODE-6369, GEODE-6404 contains risk of introducing
more failures. Are we lacking tests , reviews etc. I apologize but I was
not able to understand.
Regards
Nabarun
On Thu, Feb 14, 2019 at 11:36 AM Alexander Murmann <am...@apache.org>
wrote:
> Usually I am a proponent of cutting a branch and then fixing things on
> there where things are more stable. In this case we seem to have a large
> number of fairly serious concerns. Do we think the cost of putting this
> many fixes on develop + the release branch out-weights the benefit of less
> risk of new issues being introduced?
>
> Thoughts?
>
> Thank you, Sai for taking over!
>
> On Thu, Feb 14, 2019 at 10:32 AM Sai Boorlagadda <
> sai.boorlagadda@gmail.com>
> wrote:
>
> > I volunteer to be the release manager for 1.9.
> >
> > Sai
> >
> > On Wed, Feb 13, 2019 at 7:48 PM Alexander Murmann <am...@apache.org>
> > wrote:
> >
> > > If there are no other takers, I can act as release manager for 1.9 and
> > will
> > > cut a release branch this week.
> > >
> > >
> > > On Tue, Jan 29, 2019 at 1:50 PM Alexander Murmann <amurmann@apache.org
> >
> > > wrote:
> > >
> > > > Hi everyone!
> > > >
> > > > February 1st is approaching rapidly which means it's almost time to
> cut
> > > > the 1.9 release. Who is interested in being the release manager for
> > 1.9?
> > > >
> > > > Thank you!
> > > >
> > >
> >
>
Re: Geode 1.9 Release Manager
Posted by Alexander Murmann <am...@apache.org>.
Usually I am a proponent of cutting a branch and then fixing things on
there where things are more stable. In this case we seem to have a large
number of fairly serious concerns. Do we think the cost of putting this
many fixes on develop + the release branch out-weights the benefit of less
risk of new issues being introduced?
Thoughts?
Thank you, Sai for taking over!
On Thu, Feb 14, 2019 at 10:32 AM Sai Boorlagadda <sa...@gmail.com>
wrote:
> I volunteer to be the release manager for 1.9.
>
> Sai
>
> On Wed, Feb 13, 2019 at 7:48 PM Alexander Murmann <am...@apache.org>
> wrote:
>
> > If there are no other takers, I can act as release manager for 1.9 and
> will
> > cut a release branch this week.
> >
> >
> > On Tue, Jan 29, 2019 at 1:50 PM Alexander Murmann <am...@apache.org>
> > wrote:
> >
> > > Hi everyone!
> > >
> > > February 1st is approaching rapidly which means it's almost time to cut
> > > the 1.9 release. Who is interested in being the release manager for
> 1.9?
> > >
> > > Thank you!
> > >
> >
>
Re: Geode 1.9 Release Manager
Posted by Sai Boorlagadda <sa...@gmail.com>.
I volunteer to be the release manager for 1.9.
Sai
On Wed, Feb 13, 2019 at 7:48 PM Alexander Murmann <am...@apache.org>
wrote:
> If there are no other takers, I can act as release manager for 1.9 and will
> cut a release branch this week.
>
>
> On Tue, Jan 29, 2019 at 1:50 PM Alexander Murmann <am...@apache.org>
> wrote:
>
> > Hi everyone!
> >
> > February 1st is approaching rapidly which means it's almost time to cut
> > the 1.9 release. Who is interested in being the release manager for 1.9?
> >
> > Thank you!
> >
>
Re: Geode 1.9 Release Manager
Posted by Bruce Schuchardt <bs...@pivotal.io>.
geode-6393 was experimental and should be dropped. The fix for the
cluster-configuration deadlock will be included in the fix for GEODE-6369.
On 2/14/19 10:20 AM, Anthony Baker wrote:
> There’s also GEODE-6393 and GEODE-6369 related to auto-reconnect issues.
>
>> On Feb 14, 2019, at 9:09 AM, Nabarun Nag <nn...@apache.org> wrote:
>>
>> I think also GEODE-6391, which is to fix a NPE while propagating región
>> destroy and invalidate region messages.
>>
>> Regards
>> Naba
>>
>>
>> On Thu, Feb 14, 2019 at 9:06 AM Jason Huynh <jh...@pivotal.io> wrote:
>>
>>> I think Kirk's topic and any solution related to stats (int to long) should
>>> be resolved before cutting the branch?
>>>
>>> On Wed, Feb 13, 2019 at 7:48 PM Alexander Murmann <am...@apache.org>
>>> wrote:
>>>
>>>> If there are no other takers, I can act as release manager for 1.9 and
>>> will
>>>> cut a release branch this week.
>>>>
>>>>
>>>> On Tue, Jan 29, 2019 at 1:50 PM Alexander Murmann <am...@apache.org>
>>>> wrote:
>>>>
>>>>> Hi everyone!
>>>>>
>>>>> February 1st is approaching rapidly which means it's almost time to cut
>>>>> the 1.9 release. Who is interested in being the release manager for
>>> 1.9?
>>>>> Thank you!
>>>>>
Re: Geode 1.9 Release Manager
Posted by Jason Huynh <jh...@pivotal.io>.
Oops, I also would like to see GEODE-6404 resolved for 1.9
On Thu, Feb 14, 2019 at 10:20 AM Anthony Baker <ab...@pivotal.io> wrote:
> There’s also GEODE-6393 and GEODE-6369 related to auto-reconnect issues.
>
> > On Feb 14, 2019, at 9:09 AM, Nabarun Nag <nn...@apache.org> wrote:
> >
> > I think also GEODE-6391, which is to fix a NPE while propagating región
> > destroy and invalidate region messages.
> >
> > Regards
> > Naba
> >
> >
> > On Thu, Feb 14, 2019 at 9:06 AM Jason Huynh <jh...@pivotal.io> wrote:
> >
> >> I think Kirk's topic and any solution related to stats (int to long)
> should
> >> be resolved before cutting the branch?
> >>
> >> On Wed, Feb 13, 2019 at 7:48 PM Alexander Murmann <am...@apache.org>
> >> wrote:
> >>
> >>> If there are no other takers, I can act as release manager for 1.9 and
> >> will
> >>> cut a release branch this week.
> >>>
> >>>
> >>> On Tue, Jan 29, 2019 at 1:50 PM Alexander Murmann <amurmann@apache.org
> >
> >>> wrote:
> >>>
> >>>> Hi everyone!
> >>>>
> >>>> February 1st is approaching rapidly which means it's almost time to
> cut
> >>>> the 1.9 release. Who is interested in being the release manager for
> >> 1.9?
> >>>>
> >>>> Thank you!
> >>>>
> >>>
> >>
>
>
Re: Geode 1.9 Release Manager
Posted by Anthony Baker <ab...@pivotal.io>.
There’s also GEODE-6393 and GEODE-6369 related to auto-reconnect issues.
> On Feb 14, 2019, at 9:09 AM, Nabarun Nag <nn...@apache.org> wrote:
>
> I think also GEODE-6391, which is to fix a NPE while propagating región
> destroy and invalidate region messages.
>
> Regards
> Naba
>
>
> On Thu, Feb 14, 2019 at 9:06 AM Jason Huynh <jh...@pivotal.io> wrote:
>
>> I think Kirk's topic and any solution related to stats (int to long) should
>> be resolved before cutting the branch?
>>
>> On Wed, Feb 13, 2019 at 7:48 PM Alexander Murmann <am...@apache.org>
>> wrote:
>>
>>> If there are no other takers, I can act as release manager for 1.9 and
>> will
>>> cut a release branch this week.
>>>
>>>
>>> On Tue, Jan 29, 2019 at 1:50 PM Alexander Murmann <am...@apache.org>
>>> wrote:
>>>
>>>> Hi everyone!
>>>>
>>>> February 1st is approaching rapidly which means it's almost time to cut
>>>> the 1.9 release. Who is interested in being the release manager for
>> 1.9?
>>>>
>>>> Thank you!
>>>>
>>>
>>
Re: Geode 1.9 Release Manager
Posted by Nabarun Nag <nn...@apache.org>.
I think also GEODE-6391, which is to fix a NPE while propagating región
destroy and invalidate region messages.
Regards
Naba
On Thu, Feb 14, 2019 at 9:06 AM Jason Huynh <jh...@pivotal.io> wrote:
> I think Kirk's topic and any solution related to stats (int to long) should
> be resolved before cutting the branch?
>
> On Wed, Feb 13, 2019 at 7:48 PM Alexander Murmann <am...@apache.org>
> wrote:
>
> > If there are no other takers, I can act as release manager for 1.9 and
> will
> > cut a release branch this week.
> >
> >
> > On Tue, Jan 29, 2019 at 1:50 PM Alexander Murmann <am...@apache.org>
> > wrote:
> >
> > > Hi everyone!
> > >
> > > February 1st is approaching rapidly which means it's almost time to cut
> > > the 1.9 release. Who is interested in being the release manager for
> 1.9?
> > >
> > > Thank you!
> > >
> >
>
Re: Geode 1.9 Release Manager
Posted by Jason Huynh <jh...@pivotal.io>.
I think Kirk's topic and any solution related to stats (int to long) should
be resolved before cutting the branch?
On Wed, Feb 13, 2019 at 7:48 PM Alexander Murmann <am...@apache.org>
wrote:
> If there are no other takers, I can act as release manager for 1.9 and will
> cut a release branch this week.
>
>
> On Tue, Jan 29, 2019 at 1:50 PM Alexander Murmann <am...@apache.org>
> wrote:
>
> > Hi everyone!
> >
> > February 1st is approaching rapidly which means it's almost time to cut
> > the 1.9 release. Who is interested in being the release manager for 1.9?
> >
> > Thank you!
> >
>
Re: Geode 1.9 Release Manager
Posted by Alexander Murmann <am...@apache.org>.
If there are no other takers, I can act as release manager for 1.9 and will
cut a release branch this week.
On Tue, Jan 29, 2019 at 1:50 PM Alexander Murmann <am...@apache.org>
wrote:
> Hi everyone!
>
> February 1st is approaching rapidly which means it's almost time to cut
> the 1.9 release. Who is interested in being the release manager for 1.9?
>
> Thank you!
>