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
thin
Thanks Bruce. I will chery-pick this commit onto the new release branch.
On Tue, Feb 19, 2019 at 1:06 PM Bruce Schuchardt
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
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
stat
Just tag, I think.
On Fri, Feb 15, 2019 at 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?
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%20Reop
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 ahe
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
wrote:
> I would like to get GEODE-6369 into the next release but that can be
>
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 cu
I have merged https://github.com/apache/geode/pull/3195 just now.
-michael
On Fri, Feb 15, 2019 at 8:27 AM Sai Boorlagadda
wrote:
> BTW, Is PR #3195 is planned to merge today?
>
> On Fri, Feb 15, 2019 at 7:53 AM Sai Boorlagadda >
> wrote:
>
> > I am planning to cut the1.9 release branch today
BTW, Is PR #3195 is planned to merge today?
On Fri, Feb 15, 2019 at 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?
>
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
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
rele
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, Nabaru
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 th
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 wrote:
> I agree but not putting in these fixes mean
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
wrote:
> >
> > For the second part, I am not sure how it was determined that
>
> 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
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
wrote:
> Did we not agreed that we won't be blocking a
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-639
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
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
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
I volunteer to be the release manager for 1.9.
Sai
On Wed, Feb 13, 2019 at 7:48 PM Alexander Murmann
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
> wrote:
>
> > Hi
Oops, I also would like to see GEODE-6404 resolved for 1.9
On Thu, Feb 14, 2019 at 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 wrote:
> >
> > I think also GEODE-6391, which is to fix a NP
There’s also GEODE-6393 and GEODE-6369 related to auto-reconnect issues.
> On Feb 14, 2019, at 9:09 AM, Nabarun Nag 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:0
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 wrote:
> I think Kirk's topic and any solution related to stats (int to long) should
> be resolved before cutting the branch?
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
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
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
wrote:
> Hi everyone!
>
> February 1st is approaching rapidly which means it's almost time to cut
> the 1.9 release. Who is interested in
27 matches
Mail list logo
