Sorry for a long delay, just catching up on a ton of dev mail this morning.
FWIW, I agree that leaving feature/WIP branches in the main repository is bad
practice. The ease and flexibility of branching in Git leads to a strong
tendency towards proliferation of these things, and we really ought
This small fix avoids a failure of one cluster to communicate with the locators
of another cluster, ensuring that a proper handshake for WAN communications
occurs. Without the fix it’s possible that WAN connections will not be formed
and updates will not be transmitted between sites.
https://g
+1
On Fri, 26 Jun 2020 at 15:51, Bruce Schuchardt wrote:
> This small fix avoids a failure of one cluster to communicate with the
> locators of another cluster, ensuring that a proper handshake for WAN
> communications occurs. Without the fix it’s possible that WAN connections
> will not be for
Apologies if this has been addressed already and I missed it. In keeping with
other OSS projects, I believe it’s time we did something about removing the
insensitive term master from Geode repositories.
One choice a lot of projects appear to be going with is a simple rename from
master • main.
I am 100% in favor or dropping the master branch completely. I felt like it was
always a source of confusion. Was it the most recent release or the latest
version number. I know we have had issues with even correctly merging the
latest version back into it sometimes.
I really can’t see any rea
I agree also on removing the master branch.
As a relatively new member of the community it's been a source of confusion to
me when looking at what is said in the wiki about it
(https://cwiki.apache.org/confluence/display/GEODE/Versioning+and+Branching)
and comparing it with the actual practice.
Let's just delete it. I need to do that in my own repos as well.
On 6/26/20, 8:05 AM, "Blake Bender" wrote:
Apologies if this has been addressed already and I missed it. In keeping
with other OSS projects, I believe it’s time we did something about removing
the insensitive term master f
+1 for deleting master branch. An also for updating the wiki page about
branching that Alberto pointed out.
De: Bruce Schuchardt
Enviado: viernes, 26 de junio de 2020 17:37
Para: dev@geode.apache.org
Asunto: Re: Fate of master branch
Let's just delete it. I nee
The plugin code that spawns junit test workers on containers needs some serious
help. Aside from the benefit we would get on windows, we also are blocked on
getting to the next major version of Gradle with the current tool. I really
think it might be easier to write our own Gradle plugin at this
My guess is that there is a background thread that throws a CancelException
which is caught and logged AFTER the DistributedSystem disconnect. Any
logging after that goes to stdout logging instead of the server/locator log
file.
Otherwise, it might be a System.out or throwable.printStackTrace call
+1 to deleting. Given we tag everything properly on the other branches, I
don't see the need for it either.
On Fri, Jun 26, 2020 at 9:03 AM Alberto Bustamante Reyes
wrote:
> +1 for deleting master branch. An also for updating the wiki page about
> branching that Alberto pointed out.
> __
+1 to delete. No good reason to keep it that I know of. I think I am the third
+1 with no -1s so just do it.
Thanks,
Mark
> On Jun 26, 2020, at 9:13 AM, Alexander Murmann wrote:
>
> +1 to deleting. Given we tag everything properly on the other branches, I
> don't see the need for it either.
>
Let’s check all the repos:
geode
master is the latest released code
work is done on develop (default branch)
geode-benchmarks
master is the latest released code
work is done on develop (default branch)
geode-dotnet-core-client
master is the latest released
By just do it, I assume you mean:
- Contact delete master where not needed
- Rename master to main when needed
- Contact INFRA to change the default branch
- Update README and CI jobs as needed
Across *all* geode repos.
Anthony
> On Jun 26, 2020, at 9:38 AM, Mark Hanson wrote:
>
> +1 to del
+1
On 6/26/20, 7:58 AM, "Ju@N" wrote:
+1
On Fri, 26 Jun 2020 at 15:51, Bruce Schuchardt wrote:
> This small fix avoids a failure of one cluster to communicate with the
> locators of another cluster, ensuring that a proper handshake for WAN
> communications occurs. Withou
+1
From: Owen Nichols
Sent: Friday, June 26, 2020 9:59 AM
To: dev@geode.apache.org
Subject: Re: [PROPOSAL] merge GEODE-8195 to support/1.13 and support/1.12
+1
On 6/26/20, 7:58 AM, "Ju@N" wrote:
+1
On Fri, 26 Jun 2020 at 15:51, Bruce Schuchardt wrot
Hello All,
The core of the restore redundancy call structure has been refactored to allow
there to be a REST call to invoke a restore redundancy. At this point, looking
forward to the 1.13 release it would be great if we could fit this into the
1.13 release.
What do people think?
Thanks,
Mark
A bigger effort (but I think more correct and sustainable) would be to switch
to junit 5 where something like this could more easily be implemented.
--Jens
On 6/26/20, 9:11 AM, "Robert Houghton" wrote:
The plugin code that spawns junit test workers on containers needs some
serious help.
If the effort to do both is less than the sum of each individually then I say
lets do it.
Kirk, I recall you putting some effort into JUnit 5 at some point.
-Jake
> On Jun 26, 2020, at 11:13 AM, Jens Deppe wrote:
>
> A bigger effort (but I think more correct and sustainable) would be to swi
> On Jun 26, 2020, at 9:40 AM, Anthony Baker wrote:
>
> For geode-examples, there is more impact since master is the default branch
> and anyone who has accessed these examples would be affected. I think it’s
> still worth it to make the switch.
I wonder if it makes sense put current exampl
+1
Although normally features wouldn't really count as "critical fixes" that would
warrant inclusion after the release branch has been cut, in this case, the
internal API and gfsh commands for restore redundancy are already in the
release, and it makes much more sense to include the entire feat
+1 if we can override git’s ‘master’ default and establish ‘develop’ in its
place. Otherwise renaming to ‘main’ would solve the problem with the negative
connotations.
NB: Mark, I think the 3-vote convention is just for back-ports to the
release-branch. I don’t think of it as applying to a gene
What I am looking for is a script like following:
./regression -Z deploy \
-n \
-o \
-g \
-u \
-t \
-k \
-F \
Example:
./regression deploy -n 10 -o centos7 \
-g
~/gemfire/closed/pivotalgf-assembly/build/distributions/pivotal-gemfire-regression-0.0.0.tgz
\
+1 As Donal said, complete the feature with all the available APIs.
On 6/26/20, 11:50 AM, "Donal Evans" wrote:
+1
Although normally features wouldn't really count as "critical fixes" that
would warrant inclusion after the release branch has been cut, in this case,
the internal API an
When restore-redundancy was first proposed, the question was asked whether a
REST api would be part of that, and the answer was an emphatic "no" (largely
due to the continuing "experimental" labeling on the REST API, as I recall).
So I reject that argument that this is about "including the enti
I can appreciate your perspective. I think there are three key things when
looking at whether or not to add this to the 1.13 release or not.
1) this is a desirable feature that we were hoping to use internally at VMware
and with our current release cadence, it is unclear when the next release is
When restore-redundancy was first proposed, the question was asked whether a
REST api would be part of that, and the answer was an emphatic "no" (largely
due to the continuing "experimental" labeling on the REST API, as I recall).
So I reject that argument that this is about "including the enti
Thank Mark and Donal for detailing the risk and criticality of this change.
Since 1.13 is still waiting on a couple other issues, might as well take the
opportunity to bring this in. My vote is +1 now.
On 6/26/20, 2:32 PM, "Donal Evans" wrote:
When restore-redundancy was first proposed,
Looks good. Merge to 1.13 (if you haven't already).
-Dave
On Fri, Jun 26, 2020 at 10:05 AM Donal Evans wrote:
> +1
>
> From: Owen Nichols
> Sent: Friday, June 26, 2020 9:59 AM
> To: dev@geode.apache.org
> Subject: Re: [PROPOSAL] merge GEODE-8195 to support/1.13
OK - you've got the votes, Mark, thanks for your contribution.
I'm persuaded by the positive arguments and assurances of low risk.
All: let's focus on getting to RC1. I'm not comfortable with "as this
release has drug on for so long, it might be just about time to reset
expectations". Let's clean
30 matches
Mail list logo
