What triggers a maintenance release?

[Alberto Bustamante Reyes]

Hi all,


I have not found information about this topic in the wiki, and taking into 
account that I cannot find any "hotfix" branch in github, maybe this has not 
happened yet: I would like to ask about the criteria to create a maintenance 
release.

I suppose that a high priority bug should exist, but how is that priority 
evaluated?


If Im interested on a specific issue solution which will be included in next 
release, but I cannot wait so long, could I ask for an official maintenance 
version? Or creating my own Geode version is the only alternative?


Thanks in advance,


Alberto B.

Re: What triggers a maintenance release?

[Anthony Baker]

Great question, Alberto.  In the past we’ve done patch releases (the 3rd digit 
in X.Y.Z) due to security issues but it hasn’t been a very common occurrence. 

What issue are you running into?  Perhaps we can help with an alternative 
approach or workaround.  If you would like the project to do a patch release, I 
encourage you to make a case :-)


Anthony


> On Jul 10, 2019, at 2:02 AM, Alberto Bustamante Reyes 
>  wrote:
> 
> Hi all,
> 
> 
> I have not found information about this topic in the wiki, and taking into 
> account that I cannot find any "hotfix" branch in github, maybe this has not 
> happened yet: I would like to ask about the criteria to create a maintenance 
> release.
> 
> I suppose that a high priority bug should exist, but how is that priority 
> evaluated?
> 
> 
> If Im interested on a specific issue solution which will be included in next 
> release, but I cannot wait so long, could I ask for an official maintenance 
> version? Or creating my own Geode version is the only alternative?
> 
> 
> Thanks in advance,
> 
> 
> Alberto B.
> 
> 
> 
> 

Re: What triggers a maintenance release?

[Alberto Bustamante Reyes]

We are suffering the problem of the multiple class loaders described in 
Geode-6716, which was solved in Geode-6822 
(https://issues.apache.org/jira/browse/GEODE-6822).


De: Anthony Baker 
Enviado: miércoles, 10 de julio de 2019 17:06:59
Para: dev@geode.apache.org
Asunto: Re: What triggers a maintenance release?

Great question, Alberto.  In the past we’ve done patch releases (the 3rd digit 
in X.Y.Z) due to security issues but it hasn’t been a very common occurrence.

What issue are you running into?  Perhaps we can help with an alternative 
approach or workaround.  If you would like the project to do a patch release, I 
encourage you to make a case :-)


Anthony


> On Jul 10, 2019, at 2:02 AM, Alberto Bustamante Reyes 
>  wrote:
>
> Hi all,
>
>
> I have not found information about this topic in the wiki, and taking into 
> account that I cannot find any "hotfix" branch in github, maybe this has not 
> happened yet: I would like to ask about the criteria to create a maintenance 
> release.
>
> I suppose that a high priority bug should exist, but how is that priority 
> evaluated?
>
>
> If Im interested on a specific issue solution which will be included in next 
> release, but I cannot wait so long, could I ask for an official maintenance 
> version? Or creating my own Geode version is the only alternative?
>
>
> Thanks in advance,
>
>
> Alberto B.
>
>
>
>

[DISCUSS]: ClusterManagementService configuration objects

[Jinmei Liao]

We've been working on a new and improved ClusterManagmentService for a
while now. It allows developers/administrators to manage the clusters
through rest calls instead of having to use gfsh (more info here:
https://cwiki.apache.org/confluence/display/GEODE/Cluster+Management+Service
).

Up until now, we've been using the auto-generated POJOs from cache.xsd as
configuration objects because they contain all cache.xml has to offer. We
do this with the hope that whatever you can configure using cache.xml, you
can configure using this new model. But we also ran into these problems:
1. auto-generated code is messy, we had to make way too many adjustments to
the generated code in order to improve usage.
2. when xsd change, we would have a hard time to re-incorporate the change
we made to these objects to the newly generated code.
3. these domain objects have deprecated constructs that we do not want to
expose as public api.
4. configuration objects needs to be more intuitive/simple for users to
configure.

So we are proposing to introduce a new set of configuration objects that
are dedicated to CMS, and keep the auto-generated xml domain objects as
internal. And yes, it won't have as much attributes as those xml domain
objects in the beginning, but we are hoping they will catch up soon.

Concerns/comments?
-- 
Cheers

Jinmei

[Proposal] Refactor the Cache and Region perf stats structure.

[Mark Hanson]

Hi All,

As many of you may know our structure for our perf stats is not great. I would 
like to propose we refactor the code to have the following inheritance model, 
which Kirk and I came up with.

It is my belief that fixing this will allow future features to be implemented 
in a much less painful way.

Thoughts?

Thanks,
Mark

Re: [Proposal] Refactor the Cache and Region perf stats structure.

[Dan Smith]

Seems reasonable. I'm guessing that CachePerfImpl contains many
RegionStats. Does PartitionRegionStatsImpl just contain a single
RegionStats?

On Wed, Jul 10, 2019 at 4:49 PM Mark Hanson  wrote:

> Hi All,
>
> As many of you may know our structure for our perf stats is not great. I
> would like to propose we refactor the code to have the following
> inheritance model, which Kirk and I came up with.
>
> It is my belief that fixing this will allow future features to be
> implemented in a much less painful way.
>
> Thoughts?
>
> Thanks,
> Mark
>

Re: [Proposal] Refactor the Cache and Region perf stats structure.

[Mark Hanson]

PartitionRegionStatsImpl can contain one to many RegionStats

> On Jul 10, 2019, at 4:53 PM, Dan Smith  wrote:
> 
> Seems reasonable. I'm guessing that CachePerfImpl contains many RegionStats. 
> Does PartitionRegionStatsImpl just contain a single RegionStats?
> 
> On Wed, Jul 10, 2019 at 4:49 PM Mark Hanson  > wrote:
> Hi All,
> 
> As many of you may know our structure for our perf stats is not great. I 
> would like to propose we refactor the code to have the following inheritance 
> model, which Kirk and I came up with.
> 
> It is my belief that fixing this will allow future features to be implemented 
> in a much less painful way.
> 
> Thoughts?
> 
> Thanks,
> Mark
> 

Re: [DISCUSS]: ClusterManagementService configuration objects

[Jacob Barrett]

Are these new objects public API or internal?

> On Jul 10, 2019, at 1:16 PM, Jinmei Liao  wrote:
> 
> We've been working on a new and improved ClusterManagmentService for a
> while now. It allows developers/administrators to manage the clusters
> through rest calls instead of having to use gfsh (more info here:
> https://cwiki.apache.org/confluence/display/GEODE/Cluster+Management+Service
> ).
> 
> Up until now, we've been using the auto-generated POJOs from cache.xsd as
> configuration objects because they contain all cache.xml has to offer. We
> do this with the hope that whatever you can configure using cache.xml, you
> can configure using this new model. But we also ran into these problems:
> 1. auto-generated code is messy, we had to make way too many adjustments to
> the generated code in order to improve usage.
> 2. when xsd change, we would have a hard time to re-incorporate the change
> we made to these objects to the newly generated code.
> 3. these domain objects have deprecated constructs that we do not want to
> expose as public api.
> 4. configuration objects needs to be more intuitive/simple for users to
> configure.
> 
> So we are proposing to introduce a new set of configuration objects that
> are dedicated to CMS, and keep the auto-generated xml domain objects as
> internal. And yes, it won't have as much attributes as those xml domain
> objects in the beginning, but we are hoping they will catch up soon.
> 
> Concerns/comments?
> -- 
> Cheers
> 
> Jinmei