+1 to include the performance benchmark code. It provides an
opportunity for community to use it and develop on it (a must needed when
Geode is termed as performant data product).
On Thu, Jan 16, 2020 at 6:35 PM Robert Houghton
wrote:
> Let's not vote until there is a call to vote, folks...
>
Let's not vote until there is a call to vote, folks...
On Thu, Jan 16, 2020, 18:31 Jacob Barrett wrote:
> I would characterize my vote as 0. I really don’t care either way. Just
> sharing I think they have no value in a release.
>
> > On Jan 16, 2020, at 6:08 PM, Owen Nichols wrote:
> >
> >
I would characterize my vote as 0. I really don’t care either way. Just sharing
I think they have no value in a release.
> On Jan 16, 2020, at 6:08 PM, Owen Nichols wrote:
>
> Geode PMC has 52 members. If this were a vote, it looks like the results
> would have been:
> +1: 2 (Anthony, Dan)
>
Geode PMC has 52 members. If this were a vote, it looks like the results would
have been:
+1: 2 (Anthony, Dan)
-1: 1 (Jake)
If the next release manager were to go ahead and put geode-benchmarks in the
Geode 1.12.0 source release, at least 3 PMC members would need to be willing to
vote +1. So
> If geode-benchmarks is included, that implies that an RC cannot be
approved until reviewers can successfully run the benchmark suite from the
geode-benchmarks source distribution. Is that what we want?
I think it would be sufficient to run the tests of the benchmarks, eg
./gradlew test
> Deplo
When voting on RC candidates, PMC members "are required to download the signed
source code package, compile it as provided, and test the resulting executable
on their own platform”.
If geode-benchmarks is included, that implies that an RC cannot be approved
until reviewers can successfully run
The language “sufficient for a user to build and test the release” suggest to
me that "./gradlew test” should work (i.e. don’t release *just* src). It would
be a slippery slope to construe this guideline as a mandate to include any and
all tools, scripts, etc that may ever have been used in con
We are supposed to be including all of the source necessary to test Geode
in the source release [1] - I think that would include benchmarks as well.
I don't really see any compelling reason *not* to include the benchmarks,
let's go ahead and get them into our source release!
[1]
http://www.apache
+1 for no changes
On Wed, Jan 15, 2020 at 5:57 PM Jacob Barrett wrote:
> We can live in areas of gray that don’t require any changes. Nobody is
> asking for benchmarks so let’s not do work to add them. Nobody is
> complaining they CI is included so let’s not do work to remove them. Is it
> ideal
We can live in areas of gray that don’t require any changes. Nobody is asking
for benchmarks so let’s not do work to add them. Nobody is complaining they CI
is included so let’s not do work to remove them. Is it ideal, meh...
> On Jan 15, 2020, at 5:50 PM, Mark Hanson wrote:
>
> Just my two c
Just my two cents.
I think that we should probably strip CI into a separate repo. The key
indicator is that if something were wrong in the CI yaml, would I hold a
release for that? I think no. So that suggests to me it is a separate thing.
Same goes for benchmarks. If we were failing a benchmar
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
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
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
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
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 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
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
@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
19 matches
Mail list logo
