Hi geode-dev,
Is it possible somehow to protect all files that containing user data(or user
data itself) being stored in disk for Geode.
This includes all persistence data(OpLogs), backups and possible other files
containing user data.
Also protection is needed for all of the files potentailly u
Hello All,
It is that time again. It is time to cut a new release branch for 1.12 on
February 3rd.
We need a volunteer! No experience required. Committer status would be helpful,
but not required.
In the mean time, we should focus on ensuring the CI is stable and start
planning to cut the bra
@Anthony has twice proposed[1][2] that we start including geode-benchmarks in
our release process. Is this worth considering for the upcoming 1.12.0 release?
[1]
https://lists.apache.org/thread.html/c7bd84b6e6f5464ed674ed447fe8922097237932967b4ed1966e79d3%40%3Cdev.geode.apache.org%3E
[2]
https
Looks like the benchmarks have passed for around 30 builds in a row. +1 to
including them if they don't fail for spurious reasons between now and
cutting the release.
BTW - Do we have stats on the variance we see in the benchmark numbers? Are
we getting close to failing occasionally? What is the c
I believe the desire is to include the source code for geode-benchmarks as part
of the official geode release, much like how we include geode-examples.
> On Jan 14, 2020, at 4:07 PM, Dan Smith wrote:
>
> Looks like the benchmarks have passed for around 30 builds in a row. +1 to
> including them
On Tue, Jan 14, 2020 at 4:11 PM Owen Nichols wrote:
> I believe the desire is to include the source code for geode-benchmarks as
> part of the official geode release, much like how we include geode-examples.
>
Oh! I thought you meant running the benchmarks in the release pipeline - I
think last
I don’t think the benchmarks provide any material benefit to a user in their
current state. They are heavily tuned for our CI process which relies on very
beefy machines. Usage on other hardware will require more tuning. I don’t think
it’s worth putting the source in the release until they are i
The source is already public, so on some level a source release is no different
from a git tag. Benchmarks has matured enough that I think it makes sense to
at least start branching and tagging the geode-benchmarks repo to capture
exactly what was used in that Geode release.
Others in the dev
Until someone outside of the geode ci community is asking for it I just don’t
see utility in going through the motions of making a release for it.
> On Jan 14, 2020, at 10:13 PM, Owen Nichols wrote:
>
> The source is already public, so on some level a source release is no
> different from a
I can see your argument that geode-benchmarks is strictly part of Geode CI for
now, and CI is not “part of Geode” or generally useful to anyone outside the
Geode CI community. If so, I think it would also be a good idea to exclude
geode/ci from Geode source releases.
> On Jan 14, 2020, at 10:2
10 matches
Mail list logo
