Yes, the proposal was deprecation notice in 1.12 and remove in 1.13..
That does not leave users much time to react. So if we remove in 1.14,
then users have at least 2 release cycles before we do it.
--Udo
On 2/28/20 1:11 PM, Owen Nichols wrote:
Udo, are you proposing to deprecate in 1.12 an
+1
If the original reason for the 25 file limit was to prevent StressNewTest
taking too long, then the concourse timeout renders the restriction
redundant. Also, I'd think that if anything, the more files a PR changed,
the more interested we would be in running StressNewTest. Allowing it to
just b
Ok, thanks! I've submitted https://github.com/apache/geode/pull/4748 to
revert the change. I'll be offline for a while so feel free to merge it if
it passes.
Thanks,
Kirk
On Thu, Feb 27, 2020 at 5:19 PM Owen Nichols wrote:
> While changing a void method to have a return type does not break sour
There appears to be consensus that this is a critical fix.
The following commit has been brought into release/1.12 as the
critical fix for GEODE-7829:
git cherry-pick -x dfa3326e674278f38673c9508a13af752ae90e28
GEODE-7829 has been marked as 'resolved in' 1.12.
Regards
EB
On Fri, Feb 28, 2020
Welcome Derrick! Please shout out if you need any help.
Anthony
> On Feb 28, 2020, at 12:53 PM, Owen Nichols wrote:
>
> Welcome Derrick, you should have access to Geode Jira now
>
> https://issues.apache.org/jira/projects/GEODE/issues
>
>
>> On Feb 26, 2020, at 8:41 AM, Derrick Anderson
+1
On Fri, Feb 28, 2020 at 1:15 PM Ernest Burghardt
wrote:
> yes, it was just a transposition/typo when the defaults were
> refactored/moved
>
> On Fri, Feb 28, 2020 at 1:14 PM Owen Nichols wrote:
>
> > +1 for bringing this fix to 1.12 (assuming the change was unintentional?)
> >
> > Any ideas
yes, it was just a transposition/typo when the defaults were
refactored/moved
On Fri, Feb 28, 2020 at 1:14 PM Owen Nichols wrote:
> +1 for bringing this fix to 1.12 (assuming the change was unintentional?)
>
> Any ideas how much performance improvement this is anticipated to restore?
>
> > On Fe
+1 for bringing this fix to 1.12 (assuming the change was unintentional?)
Any ideas how much performance improvement this is anticipated to restore?
> On Feb 28, 2020, at 1:06 PM, Ernest Burghardt wrote:
>
> bumping this out to DevList as something went wrong in the mail system...
>
> On 2020/
Hello devs,
I'd like to include the fix for GEODE-782 [1] in release 1.12.0.
During a refactor the default ack-wait-threshold was changed from 15
to 51. This will affect any deployment that doesn’t set its own
threshold.
The ack-wait-threshold determines how long we wait for a response to a
me
Udo, are you proposing to deprecate in 1.12 and remove in 1.14?
> On Feb 28, 2020, at 1:03 PM, Udo Kohlmeyer wrote:
>
> +1 to adding the deprecation. But I would prefer that we give users more
> notice than 3 months.
>
> maybe we deprecate it in 1.14
>
> --Udo
>
> On 2/28/20 1:00 PM, Ernest
got it... domain still looks weird
On Fri, Feb 28, 2020 at 1:10 PM Bruce Schuchardt
wrote:
> I’m switching to a new email account.
>
I’m switching to a new email account.
bumping this out to DevList as something went wrong in the mail system...
On 2020/02/28 19:27:42, Bruce Schuchardt wrote:
> During a refactor the default ack-wait-threshold was changed from 15 to 51.
> This will affect any deployment that doesn’t set its own threshold.
>
> The ack-wait-thresh
+1 to adding the deprecation. But I would prefer that we give users more
notice than 3 months.
maybe we deprecate it in 1.14
--Udo
On 2/28/20 1:00 PM, Ernest Burghardt wrote:
+1
seems reasonable to do this for 1.12 and be ahead of the game, @Owen would
you please spawn that as a separate rel
+1
On 2/28/20, 11:43 AM, "Bill Burcham" wrote:
I propose we deprecate Geode’s proprietary UDP message privacy algorithm
based on the Diffie-Hellman key exchange protocol. This would deprecate:
ConfigurationProperties.SECURITY_UDP_DHALGO
String DistributionConfig.getSec
+1
seems reasonable to do this for 1.12 and be ahead of the game, @Owen would
you please spawn that as a separate release 1.12 thread? thanks, eB
On Fri, Feb 28, 2020 at 11:56 AM Owen Nichols wrote:
> +1
>
> We should have done this as soon as SSL/TLS was ready. Better late than
> never!
>
> W
Welcome Derrick, you should have access to Geode Jira now
https://issues.apache.org/jira/projects/GEODE/issues
> On Feb 26, 2020, at 8:41 AM, Derrick Anderson
> wrote:
>
> Hi!
>
> I am planning on contributing and would like contributor access in Jira.
>
> My username is deanderson
>
> Tha
Hi!
I am planning on contributing and would like contributor access in Jira.
My username is deanderson
Thank you so much for your help
Currently, StressNewTest will turn green WITHOUT RUNNING ANY TESTS if it thinks
(often wrongly) that more than 25 test files were touched.
This is both dishonest (it can give a false green) AND totally unnecessary
(concourse already applies a timeout to StressNewTest, currently set at 6
hours,
+1
We should have done this as soon as SSL/TLS was ready. Better late than never!
While we normally wait until a major release to remove deprecated stuff, there
is some precedent for removing insecure encryption algorithms sooner (Java has
done this even in patch releases). We should consider
What help is needed in this effort?
Regards
Naba
On Fri, Feb 28, 2020 at 11:35 AM Mark Hanson wrote:
> Alright, so basically it seems like people are not ok with the not
> requiring stressnewtest approach. So I guess that means that we need to
> identify -1s willing to help resolve this problem
I propose we deprecate Geode’s proprietary UDP message privacy algorithm
based on the Diffie-Hellman key exchange protocol. This would deprecate:
ConfigurationProperties.SECURITY_UDP_DHALGO
String DistributionConfig.getSecurityUDPDHAlgo()
void DistributionConfig.setSecurityUDPDHAlgo(String attVa
Alright, so basically it seems like people are not ok with the not requiring
stressnewtest approach. So I guess that means that we need to identify -1s
willing to help resolve this problem…
Who would like to help?
Thanks,
Mark
> On Feb 28, 2020, at 11:12 AM, Ernest Burghardt wrote:
>
> -1 to
During a refactor the default ack-wait-threshold was changed from 15 to 51.
This will affect any deployment that doesn’t set its own threshold.
The ack-wait-threshold determines how long we wait for a response to a message,
such as replication of a put(), before taking some action.
-1 to limiting any tests... if there are issues with the tests let's fix
that. we have too many commits coming in with little or no testing over
new/changed code, so I can't see how removing any existing test coverage as
a good idea
Best,
EB
On Fri, Feb 28, 2020 at 10:58 AM Mark Hanson wrote:
Hello Owen,
Unfortunately I don't have the answer to that question... I
never worked through the Geode Benchmarks so I don't know exactly what
they're testing/validating.
Best regards.
On Fri, 28 Feb 2020 at 18:52, Owen Nichols wrote:
> Thanks Juan, this is fantastic work discovering and mitiga
Just to make sure we are clear, I am not suggesting that we disable
stressnewtest, but that we make it not required. It would still run and provide
feedback, but it would not give us an unwarranted green in my approach.
> On Feb 28, 2020, at 10:49 AM, Ju@N wrote:
>
> +1 to what Owen said, I do
Thanks Juan, this is fantastic work discovering and mitigating this!
The Benchmarks tests in our pipeline are supposed to catch performance
degradations exceeding 5%. We should all be concerned, how did a 7%
degradation slip through?
> On Feb 28, 2020, at 3:48 AM, Ju@N wrote:
>
> Hello devs,
+1 to what Owen said, I don't think disabling *StressNewTest* is a
good idea.
On Fri, 28 Feb 2020 at 18:35, Owen Nichols wrote:
> -1 to making StressNew not required
>
> +1 to eliminating the current loophole — StressNew should never give a
> free pass.
>
> Any time your PR is having trouble pas
-1 to making StressNew not required
+1 to eliminating the current loophole — StressNew should never give a free
pass.
Any time your PR is having trouble passing StressNew, please bring it up on the
dev list. We can review on a case-by-case basis and decide whether to try
increasing the timeo
Hi All,
Proposal: Force StressNewTest to fail a change with 25 or more files rather
than pass it without running it.
Currently, the StressNewTest job in the pipeline will just pass a job that has
more than 25 files changed. It will be marked as green with no work done. There
are reasons, relat
Another affect is code deployment onto/into the server, which
could/would reference a change (binary) API. Users generally don't
recompile the code they redeploy. The NoSuchMethod is now harder to
track down.
--Udo
On 2/28/20 8:59 AM, Anthony Baker wrote:
If I run the japi-compliance-checke
If I run the japi-compliance-checker [1] against the 1.12 release branch and
develop this change pops up as a binary incompatibility. As Owen noted, this
would require recompilation to avoid NoSuchMethod errors.
One effect this could have is that a library built on top of Geode (e.g.
Spring) w
There appears to be consensus that this is a critical fix.
The following commit has been brought into release/1.12 as the
critical fix for GEODE-7820:
git cherry-pick -x ca7ccbce73d436005fe027f31ee910ee9beeb769
GEODE-7820 has been marked as 'resolved in' 1.12.
Regards
EB
On Fri, Feb 28, 2020
+1
On Fri, Feb 28, 2020 at 7:40 AM Owen Nichols wrote:
> +1
>
> On Fri, Feb 28, 2020 at 7:38 AM Udo Kohlmeyer wrote:
>
> > +1, Keep the improvements coming...
> >
> > On 2/28/20 3:48 AM, Ju@N wrote:
> > > Hello devs,
> > >
> > > I'd like to include the fix for GEODE-7820 [1] in release 1.12.0.
+1
On Fri, Feb 28, 2020 at 7:38 AM Udo Kohlmeyer wrote:
> +1, Keep the improvements coming...
>
> On 2/28/20 3:48 AM, Ju@N wrote:
> > Hello devs,
> >
> > I'd like to include the fix for GEODE-7820 [1] in release 1.12.0.
> > The change avoid unnecessary transformations between java collections an
+1, Keep the improvements coming...
On 2/28/20 3:48 AM, Ju@N wrote:
Hello devs,
I'd like to include the fix for GEODE-7820 [1] in release 1.12.0.
The change avoid unnecessary transformations between java collections and
primitive arrays for every message sent within a Geode cluster (see the
Geo
Hello devs,
I'd like to include the fix for GEODE-7820 [1] in release 1.12.0.
The change avoid unnecessary transformations between java collections and
primitive arrays for every message sent within a Geode cluster (see the
Geode tickets for further details).
The SHA is ca7ccbce73d436005fe027f31ee
39 matches
Mail list logo
