Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop

[Aaron Lindsey]

+1 to keep only "Squash and merge" and "Rebase and merge".

Aaron Lindsey


From: Robert Houghton 
Sent: Monday, June 28, 2021 2:31 PM
To: dev@geode.apache.org
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop

I for one do not like revisionist history (rebase) but understand that linear 
history is easier for bisect.


From: Blake Bender 
Date: Monday, June 28, 2021 at 2:24 PM
To: dev@geode.apache.org 
Subject: RE: Fw: [DISCUSS] Rebase and Squash Options on Github develop
+1, only because I only get one vote.  Merge commits in develop are a scourge, 
IMO, and should be avoided in almost all instances.

Blake


-Original Message-
From: Donal Evans 
Sent: Monday, June 28, 2021 2:22 PM
To: dev@geode.apache.org
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop

I definitely approve of this proposal. I accidentally merged (rather than 
squashed and merged) a PR a while back because my GitHub session had expired 
and refreshing the page after trying to squash and merge resulted in the 
default merge option being used, much to my frustration. I've yet to see any 
explanation of why we would need to merge PRs rather than squash and 
merge/rebase and merge, so removing it as an option just seems like a good idea.

From: Nabarun Nag 
Sent: Monday, June 28, 2021 1:06 PM
To: Owen Nichols ; dev@geode.apache.org 

Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop

Just a clarification.

The options I am proposing to be kept in the PRs are:

  *   Squash and merge
  *   Rebase and merge

Regards,
Nabarun

From: Owen Nichols 
Sent: Monday, June 28, 2021 1:03 PM
To: Nabarun Nag ; dev@geode.apache.org 
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop

Sounds like a good idea. I can't find any example of an intentional merge 
commit on develop...but plenty of accidental ones.

Upon releases we do a command line merge commit to the main trunk, which should 
still be fine as this proposal only applies to PRs.

I agree with still allowing rebase commits. I have seen several PRs use them to 
good effect.

You can disable merge commits through .asf.yaml, so changing the setting is as 
easy as opening a PR (and, if we don't like it, reverting is just as easy)


---
Sent from Workspace ONE 
Boxer

On June 28, 2021 at 12:38:50 PM PDT, Nabarun Nag  wrote:
Hi all,

Last year, we had a discussion on rebase and squash merge PRs to the develop 
branch,

  *   to have linear git history
  *   help with bisecting
  *   easier root cause analysis of failures
  *   easier to backport changes

However, many developers have reached out mentioning that sometimes they have 
clicked the merge button in hurry when they meant to rebase/squash. Once 
clicked there is no going back. All of them suggested that to have the GitHub 
setting on develop branch to rebase and squash merge option and hence there is 
no room for mistakes to occur.

I would like to propose to that we set the GitHub setting on develop PR to 
rebase and squash buttons.

Please do note that this is reversible and can be changed back, hence there is 
no harm in trying it out.


Regards
Nabarun Nag



From: Owen Nichols (Pivotal) 
Sent: Thursday, April 9, 2020 11:45 AM
To: dev@geode.apache.org 
Subject: Re: [REQUEST] Squash merge please

I've noticed quite a few PRs in the last week that were merged with "Merge" 
rather than "Squash and Merge".

While the community consensus was to continue to allow all merge options, 
please try to default to "Squash and Merge" whenever you can to keep history as 
linear as possible. GitHub will save the last method you used in a cookie, 
which helps, but then it's easy to miss when it resets itself back to the 
default of "Merge" some months later because you cleared cookies, changed 
browsers, etc.

> On Oct 22, 2019, at 5:12 PM, Nabarun Nag  wrote:
>
> Hi Geode Committers,
>
> A kind request for using squash commit instead of using merge.
> This will really help us in our bisect operations when a regression/flakiness 
> in the product is introduced. We can automate and go through fewer commits 
> faster, avoiding commits like "spotless fix" and "re-trigger precheck-in" or 
> other minor commits in the merged branch.
>
> Also, please use the commit format : (helps us to know who worked on it, what 
> is the history)
> GEODE-: 
>
> * explanation line 1
>

Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop

[Robert Houghton]

I for one do not like revisionist history (rebase) but understand that linear 
history is easier for bisect.


From: Blake Bender 
Date: Monday, June 28, 2021 at 2:24 PM
To: dev@geode.apache.org 
Subject: RE: Fw: [DISCUSS] Rebase and Squash Options on Github develop
+1, only because I only get one vote.  Merge commits in develop are a scourge, 
IMO, and should be avoided in almost all instances.

Blake


-Original Message-
From: Donal Evans 
Sent: Monday, June 28, 2021 2:22 PM
To: dev@geode.apache.org
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop

I definitely approve of this proposal. I accidentally merged (rather than 
squashed and merged) a PR a while back because my GitHub session had expired 
and refreshing the page after trying to squash and merge resulted in the 
default merge option being used, much to my frustration. I've yet to see any 
explanation of why we would need to merge PRs rather than squash and 
merge/rebase and merge, so removing it as an option just seems like a good idea.

From: Nabarun Nag 
Sent: Monday, June 28, 2021 1:06 PM
To: Owen Nichols ; dev@geode.apache.org 

Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop

Just a clarification.

The options I am proposing to be kept in the PRs are:

  *   Squash and merge
  *   Rebase and merge

Regards,
Nabarun

From: Owen Nichols 
Sent: Monday, June 28, 2021 1:03 PM
To: Nabarun Nag ; dev@geode.apache.org 
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop

Sounds like a good idea. I can't find any example of an intentional merge 
commit on develop...but plenty of accidental ones.

Upon releases we do a command line merge commit to the main trunk, which should 
still be fine as this proposal only applies to PRs.

I agree with still allowing rebase commits. I have seen several PRs use them to 
good effect.

You can disable merge commits through .asf.yaml, so changing the setting is as 
easy as opening a PR (and, if we don't like it, reverting is just as easy)


---
Sent from Workspace ONE 
Boxer

On June 28, 2021 at 12:38:50 PM PDT, Nabarun Nag  wrote:
Hi all,

Last year, we had a discussion on rebase and squash merge PRs to the develop 
branch,

  *   to have linear git history
  *   help with bisecting
  *   easier root cause analysis of failures
  *   easier to backport changes

However, many developers have reached out mentioning that sometimes they have 
clicked the merge button in hurry when they meant to rebase/squash. Once 
clicked there is no going back. All of them suggested that to have the GitHub 
setting on develop branch to rebase and squash merge option and hence there is 
no room for mistakes to occur.

I would like to propose to that we set the GitHub setting on develop PR to 
rebase and squash buttons.

Please do note that this is reversible and can be changed back, hence there is 
no harm in trying it out.


Regards
Nabarun Nag



From: Owen Nichols (Pivotal) 
Sent: Thursday, April 9, 2020 11:45 AM
To: dev@geode.apache.org 
Subject: Re: [REQUEST] Squash merge please

I've noticed quite a few PRs in the last week that were merged with "Merge" 
rather than "Squash and Merge".

While the community consensus was to continue to allow all merge options, 
please try to default to "Squash and Merge" whenever you can to keep history as 
linear as possible. GitHub will save the last method you used in a cookie, 
which helps, but then it's easy to miss when it resets itself back to the 
default of "Merge" some months later because you cleared cookies, changed 
browsers, etc.

> On Oct 22, 2019, at 5:12 PM, Nabarun Nag  wrote:
>
> Hi Geode Committers,
>
> A kind request for using squash commit instead of using merge.
> This will really help us in our bisect operations when a regression/flakiness 
> in the product is introduced. We can automate and go through fewer commits 
> faster, avoiding commits like "spotless fix" and "re-trigger precheck-in" or 
> other minor commits in the merged branch.
>
> Also, please use the commit format : (helps us to know who worked on it, what 
> is the history)
> GEODE-: 
>
> * explanation line 1
> * explanation line 2
>
> This is not a rule or anything, but a request to help out your fellow 
> committers in quickly detecting a problem.
>
> For inspiration, we can look into Apache Kafka / Spark where they have a 
> complete linear graph for their main 

RE: Fw: [DISCUSS] Rebase and Squash Options on Github develop

[Blake Bender]

+1, only because I only get one vote.  Merge commits in develop are a scourge, 
IMO, and should be avoided in almost all instances.

Blake


-Original Message-
From: Donal Evans  
Sent: Monday, June 28, 2021 2:22 PM
To: dev@geode.apache.org
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop

I definitely approve of this proposal. I accidentally merged (rather than 
squashed and merged) a PR a while back because my GitHub session had expired 
and refreshing the page after trying to squash and merge resulted in the 
default merge option being used, much to my frustration. I've yet to see any 
explanation of why we would need to merge PRs rather than squash and 
merge/rebase and merge, so removing it as an option just seems like a good idea.

From: Nabarun Nag 
Sent: Monday, June 28, 2021 1:06 PM
To: Owen Nichols ; dev@geode.apache.org 

Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop

Just a clarification.

The options I am proposing to be kept in the PRs are:

  *   Squash and merge
  *   Rebase and merge

Regards,
Nabarun

From: Owen Nichols 
Sent: Monday, June 28, 2021 1:03 PM
To: Nabarun Nag ; dev@geode.apache.org 
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop

Sounds like a good idea. I can't find any example of an intentional merge 
commit on develop...but plenty of accidental ones.

Upon releases we do a command line merge commit to the main trunk, which should 
still be fine as this proposal only applies to PRs.

I agree with still allowing rebase commits. I have seen several PRs use them to 
good effect.

You can disable merge commits through .asf.yaml, so changing the setting is as 
easy as opening a PR (and, if we don't like it, reverting is just as easy)


---
Sent from Workspace ONE 
Boxer

On June 28, 2021 at 12:38:50 PM PDT, Nabarun Nag  wrote:
Hi all,

Last year, we had a discussion on rebase and squash merge PRs to the develop 
branch,

  *   to have linear git history
  *   help with bisecting
  *   easier root cause analysis of failures
  *   easier to backport changes

However, many developers have reached out mentioning that sometimes they have 
clicked the merge button in hurry when they meant to rebase/squash. Once 
clicked there is no going back. All of them suggested that to have the GitHub 
setting on develop branch to rebase and squash merge option and hence there is 
no room for mistakes to occur.

I would like to propose to that we set the GitHub setting on develop PR to 
rebase and squash buttons.

Please do note that this is reversible and can be changed back, hence there is 
no harm in trying it out.


Regards
Nabarun Nag



From: Owen Nichols (Pivotal) 
Sent: Thursday, April 9, 2020 11:45 AM
To: dev@geode.apache.org 
Subject: Re: [REQUEST] Squash merge please

I've noticed quite a few PRs in the last week that were merged with "Merge" 
rather than "Squash and Merge".

While the community consensus was to continue to allow all merge options, 
please try to default to "Squash and Merge" whenever you can to keep history as 
linear as possible. GitHub will save the last method you used in a cookie, 
which helps, but then it's easy to miss when it resets itself back to the 
default of "Merge" some months later because you cleared cookies, changed 
browsers, etc.

> On Oct 22, 2019, at 5:12 PM, Nabarun Nag  wrote:
>
> Hi Geode Committers,
>
> A kind request for using squash commit instead of using merge.
> This will really help us in our bisect operations when a regression/flakiness 
> in the product is introduced. We can automate and go through fewer commits 
> faster, avoiding commits like "spotless fix" and "re-trigger precheck-in" or 
> other minor commits in the merged branch.
>
> Also, please use the commit format : (helps us to know who worked on it, what 
> is the history)
> GEODE-: 
>
> * explanation line 1
> * explanation line 2
>
> This is not a rule or anything, but a request to help out your fellow 
> committers in quickly detecting a problem.
>
> For inspiration, we can look into Apache Kafka / Spark where they have a 
> complete linear graph for their main branch HEAD [see attachment]
>
> Regards
> Naba.
>
>

Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop

[Donal Evans]

I definitely approve of this proposal. I accidentally merged (rather than 
squashed and merged) a PR a while back because my GitHub session had expired 
and refreshing the page after trying to squash and merge resulted in the 
default merge option being used, much to my frustration. I've yet to see any 
explanation of why we would need to merge PRs rather than squash and 
merge/rebase and merge, so removing it as an option just seems like a good idea.

From: Nabarun Nag 
Sent: Monday, June 28, 2021 1:06 PM
To: Owen Nichols ; dev@geode.apache.org 

Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop

Just a clarification.

The options I am proposing to be kept in the PRs are:

  *   Squash and merge
  *   Rebase and merge

Regards,
Nabarun

From: Owen Nichols 
Sent: Monday, June 28, 2021 1:03 PM
To: Nabarun Nag ; dev@geode.apache.org 
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop

Sounds like a good idea. I can’t find any example of an intentional merge 
commit on develop…but plenty of accidental ones.

Upon releases we do a command line merge commit to the main trunk, which should 
still be fine as this proposal only applies to PRs.

I agree with still allowing rebase commits. I have seen several PRs use them to 
good effect.

You can disable merge commits through .asf.yaml, so changing the setting is as 
easy as opening a PR (and, if we don’t like it, reverting is just as easy)


---
Sent from Workspace ONE 
Boxer

On June 28, 2021 at 12:38:50 PM PDT, Nabarun Nag  wrote:
Hi all,

Last year, we had a discussion on rebase and squash merge PRs to the develop 
branch,

  *   to have linear git history
  *   help with bisecting
  *   easier root cause analysis of failures
  *   easier to backport changes

However, many developers have reached out mentioning that sometimes they have 
clicked the merge button in hurry when they meant to rebase/squash. Once 
clicked there is no going back. All of them suggested that to have the GitHub 
setting on develop branch to rebase and squash merge option and hence there is 
no room for mistakes to occur.

I would like to propose to that we set the GitHub setting on develop PR to 
rebase and squash buttons.

Please do note that this is reversible and can be changed back, hence there is 
no harm in trying it out.


Regards
Nabarun Nag



From: Owen Nichols (Pivotal) 
Sent: Thursday, April 9, 2020 11:45 AM
To: dev@geode.apache.org 
Subject: Re: [REQUEST] Squash merge please

I’ve noticed quite a few PRs in the last week that were merged with “Merge” 
rather than “Squash and Merge”.

While the community consensus was to continue to allow all merge options, 
please try to default to “Squash and Merge” whenever you can to keep history as 
linear as possible. GitHub will save the last method you used in a cookie, 
which helps, but then it’s easy to miss when it resets itself back to the 
default of “Merge” some months later because you cleared cookies, changed 
browsers, etc.

> On Oct 22, 2019, at 5:12 PM, Nabarun Nag  wrote:
>
> Hi Geode Committers,
>
> A kind request for using squash commit instead of using merge.
> This will really help us in our bisect operations when a regression/flakiness 
> in the product is introduced. We can automate and go through fewer commits 
> faster, avoiding commits like "spotless fix" and "re-trigger precheck-in" or 
> other minor commits in the merged branch.
>
> Also, please use the commit format : (helps us to know who worked on it, what 
> is the history)
> GEODE-: 
>
> * explanation line 1
> * explanation line 2
>
> This is not a rule or anything, but a request to help out your fellow 
> committers in quickly detecting a problem.
>
> For inspiration, we can look into Apache Kafka / Spark where they have a 
> complete linear graph for their main branch HEAD [see attachment]
>
> Regards
> Naba.
>
>

Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop

[Nabarun Nag]

Just a clarification.

The options I am proposing to be kept in the PRs are:

  *   Squash and merge
  *   Rebase and merge

Regards,
Nabarun

From: Owen Nichols 
Sent: Monday, June 28, 2021 1:03 PM
To: Nabarun Nag ; dev@geode.apache.org 
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop

Sounds like a good idea. I can’t find any example of an intentional merge 
commit on develop…but plenty of accidental ones.

Upon releases we do a command line merge commit to the main trunk, which should 
still be fine as this proposal only applies to PRs.

I agree with still allowing rebase commits. I have seen several PRs use them to 
good effect.

You can disable merge commits through .asf.yaml, so changing the setting is as 
easy as opening a PR (and, if we don’t like it, reverting is just as easy)


---
Sent from Workspace ONE Boxer

On June 28, 2021 at 12:38:50 PM PDT, Nabarun Nag  wrote:
Hi all,

Last year, we had a discussion on rebase and squash merge PRs to the develop 
branch,

  *   to have linear git history
  *   help with bisecting
  *   easier root cause analysis of failures
  *   easier to backport changes

However, many developers have reached out mentioning that sometimes they have 
clicked the merge button in hurry when they meant to rebase/squash. Once 
clicked there is no going back. All of them suggested that to have the GitHub 
setting on develop branch to rebase and squash merge option and hence there is 
no room for mistakes to occur.

I would like to propose to that we set the GitHub setting on develop PR to 
rebase and squash buttons.

Please do note that this is reversible and can be changed back, hence there is 
no harm in trying it out.


Regards
Nabarun Nag



From: Owen Nichols (Pivotal) 
Sent: Thursday, April 9, 2020 11:45 AM
To: dev@geode.apache.org 
Subject: Re: [REQUEST] Squash merge please

I’ve noticed quite a few PRs in the last week that were merged with “Merge” 
rather than “Squash and Merge”.

While the community consensus was to continue to allow all merge options, 
please try to default to “Squash and Merge” whenever you can to keep history as 
linear as possible. GitHub will save the last method you used in a cookie, 
which helps, but then it’s easy to miss when it resets itself back to the 
default of “Merge” some months later because you cleared cookies, changed 
browsers, etc.

> On Oct 22, 2019, at 5:12 PM, Nabarun Nag  wrote:
>
> Hi Geode Committers,
>
> A kind request for using squash commit instead of using merge.
> This will really help us in our bisect operations when a regression/flakiness 
> in the product is introduced. We can automate and go through fewer commits 
> faster, avoiding commits like "spotless fix" and "re-trigger precheck-in" or 
> other minor commits in the merged branch.
>
> Also, please use the commit format : (helps us to know who worked on it, what 
> is the history)
> GEODE-: 
>
> * explanation line 1
> * explanation line 2
>
> This is not a rule or anything, but a request to help out your fellow 
> committers in quickly detecting a problem.
>
> For inspiration, we can look into Apache Kafka / Spark where they have a 
> complete linear graph for their main branch HEAD [see attachment]
>
> Regards
> Naba.
>
>

Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop

[Owen Nichols]

Sounds like a good idea. I can’t find any example of an intentional merge 
commit on develop…but plenty of accidental ones.

Upon releases we do a command line merge commit to the main trunk, which should 
still be fine as this proposal only applies to PRs.

I agree with still allowing rebase commits. I have seen several PRs use them to 
good effect.

You can disable merge commits through .asf.yaml, so changing the setting is as 
easy as opening a PR (and, if we don’t like it, reverting is just as easy)


---
Sent from Workspace ONE Boxer

On June 28, 2021 at 12:38:50 PM PDT, Nabarun Nag  wrote:
Hi all,

Last year, we had a discussion on rebase and squash merge PRs to the develop 
branch,

  *   to have linear git history
  *   help with bisecting
  *   easier root cause analysis of failures
  *   easier to backport changes

However, many developers have reached out mentioning that sometimes they have 
clicked the merge button in hurry when they meant to rebase/squash. Once 
clicked there is no going back. All of them suggested that to have the GitHub 
setting on develop branch to rebase and squash merge option and hence there is 
no room for mistakes to occur.

I would like to propose to that we set the GitHub setting on develop PR to 
rebase and squash buttons.

Please do note that this is reversible and can be changed back, hence there is 
no harm in trying it out.


Regards
Nabarun Nag



From: Owen Nichols (Pivotal) 
Sent: Thursday, April 9, 2020 11:45 AM
To: dev@geode.apache.org 
Subject: Re: [REQUEST] Squash merge please

I’ve noticed quite a few PRs in the last week that were merged with “Merge” 
rather than “Squash and Merge”.

While the community consensus was to continue to allow all merge options, 
please try to default to “Squash and Merge” whenever you can to keep history as 
linear as possible. GitHub will save the last method you used in a cookie, 
which helps, but then it’s easy to miss when it resets itself back to the 
default of “Merge” some months later because you cleared cookies, changed 
browsers, etc.

> On Oct 22, 2019, at 5:12 PM, Nabarun Nag  wrote:
>
> Hi Geode Committers,
>
> A kind request for using squash commit instead of using merge.
> This will really help us in our bisect operations when a regression/flakiness 
> in the product is introduced. We can automate and go through fewer commits 
> faster, avoiding commits like "spotless fix" and "re-trigger precheck-in" or 
> other minor commits in the merged branch.
>
> Also, please use the commit format : (helps us to know who worked on it, what 
> is the history)
> GEODE-: 
>
> * explanation line 1
> * explanation line 2
>
> This is not a rule or anything, but a request to help out your fellow 
> committers in quickly detecting a problem.
>
> For inspiration, we can look into Apache Kafka / Spark where they have a 
> complete linear graph for their main branch HEAD [see attachment]
>
> Regards
> Naba.
>
>

Re: [DISCUSS] Rebase and Squash Options on Github develop

[Jacob Barrett]

> On Jun 28, 2021, at 12:38 PM, Nabarun Nag  wrote:
> 
> 
> I would like to propose to that we set the GitHub setting on develop PR to 
> rebase and squash buttons.

Does this proposal remove the option to “Rebase and Merge?

Fw: [DISCUSS] Rebase and Squash Options on Github develop

[Nabarun Nag]

Hi all,

Last year, we had a discussion on rebase and squash merge PRs to the develop 
branch,

  *   to have linear git history
  *   help with bisecting
  *   easier root cause analysis of failures
  *   easier to backport changes

However, many developers have reached out mentioning that sometimes they have 
clicked the merge button in hurry when they meant to rebase/squash. Once 
clicked there is no going back. All of them suggested that to have the GitHub 
setting on develop branch to rebase and squash merge option and hence there is 
no room for mistakes to occur.

I would like to propose to that we set the GitHub setting on develop PR to 
rebase and squash buttons.

Please do note that this is reversible and can be changed back, hence there is 
no harm in trying it out.


Regards
Nabarun Nag



From: Owen Nichols (Pivotal) 
Sent: Thursday, April 9, 2020 11:45 AM
To: dev@geode.apache.org 
Subject: Re: [REQUEST] Squash merge please

I’ve noticed quite a few PRs in the last week that were merged with “Merge” 
rather than “Squash and Merge”.

While the community consensus was to continue to allow all merge options, 
please try to default to “Squash and Merge” whenever you can to keep history as 
linear as possible. GitHub will save the last method you used in a cookie, 
which helps, but then it’s easy to miss when it resets itself back to the 
default of “Merge” some months later because you cleared cookies, changed 
browsers, etc.

> On Oct 22, 2019, at 5:12 PM, Nabarun Nag  wrote:
>
> Hi Geode Committers,
>
> A kind request for using squash commit instead of using merge.
> This will really help us in our bisect operations when a regression/flakiness 
> in the product is introduced. We can automate and go through fewer commits 
> faster, avoiding commits like "spotless fix" and "re-trigger precheck-in" or 
> other minor commits in the merged branch.
>
> Also, please use the commit format : (helps us to know who worked on it, what 
> is the history)
> GEODE-: 
>
> * explanation line 1
> * explanation line 2
>
> This is not a rule or anything, but a request to help out your fellow 
> committers in quickly detecting a problem.
>
> For inspiration, we can look into Apache Kafka / Spark where they have a 
> complete linear graph for their main branch HEAD [see attachment]
>
> Regards
> Naba.
>
>

Re: CFP for ApacheCon 2021 closes in ONE WEEK

[Anthony Baker]

Hi Greg, great news!  Forwarding your acceptance over to Rich and the ApacheCon 
planning team.  Thanks!

Anthony


> On Jun 28, 2021, at 11:19 AM, Gregory Green  wrote:
> 
> Hello team,
> 
> I do not see where I can accept the invite in the following link/info?
> 
> Dear Gregory Green,
> 
> Congratulations! We are pleased to tell you that your talk, "OLTP Application 
> Data Services with Apache Geode”
> has been accepted for ApacheCon 2021. (If you submitted additional proposals, 
> you
> will receive separate notifications regarding each proposal.)
> 
> Please confirm that you will be attending by responding to this email. You 
> will also need to register for the event, at 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.apachecon.com%2Facah2021%2Fregister.htmldata=04%7C01%7Cbakera%40vmware.com%7C3035655129e94260176508d93a633c54%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637605020159625250%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=0BdAHjnh2hqid63H8a9bTE%2F8HjG11XUB0GvTpeehR5U%3Dreserved=0,
>  in order to be able to give your presentation. Please do not put this off, 
> as that will make the scheduling process more difficult - please go do that 
> now. Thanks.
> 
> With regards,
> The team behind ApacheCon 2021
> 
> 
> 
> -
> Gregory Green | Advisor Solution Engineer | Tanzu Data 
> Mobile: 732.737.7119| Email: grego...@vmware.com 
> --
> Articles/Videos
> Monoliths to Microservices? Don’t Forget to Transform the Data Layer 
> 
> A Caching Approach to Data Transformation of Legacy RDBMS 
> 
> How to Build Modern Data Pipelines with GemFire and SCDF 
> 
> GemFire AWS Quickstart 
> 
> 
> 
> 
> On 4/23/21, 11:03 AM, "Rich Bowen"  wrote:
> 
>[You are receiving this because you're subscribed to one or more dev@
>mailing lists for an Apache project, or the ApacheCon Announce list.]
> 
>Time is running out to submit your talk for ApacheCon 2021.
> 
>The Call for Presentations for ApacheCon @Home 2021, focused on Europe
>and North America time zones, closes May 3rd, and is at
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.apachecon.com%2Facah2021%2Fcfp.htmldata=04%7C01%7Cbakera%40vmware.com%7C3035655129e94260176508d93a633c54%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637605020159625250%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=DciPvLuH%2BJGlMqt9P85EKwL5B9fHF2PVeQ9PtXSGrLg%3Dreserved=0
> 
>The CFP for ApacheCon Asia, focused on Asia/Pacific time zones, is at
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapachecon.com%2Facasia2021%2Fcfp.htmldata=04%7C01%7Cbakera%40vmware.com%7C3035655129e94260176508d93a633c54%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637605020159625250%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=YiYaphF%2FVjBBSvDf4BLqydA%2BGzx1Gs2rWffWZaANCvo%3Dreserved=0
>  and also closes on May 3rd.
> 
>ApacheCon is our main event, featuring content from any and all of our
>projects, and is your best opportunity to get your project in front of
>the largest audience of 

Re: CFP for ApacheCon 2021 closes in ONE WEEK

[Gregory Green]

Hello team,

I do not see where I can accept the invite in the following link/info?

Dear Gregory Green,

Congratulations! We are pleased to tell you that your talk, "OLTP Application 
Data Services with Apache Geode”
has been accepted for ApacheCon 2021. (If you submitted additional proposals, 
you
will receive separate notifications regarding each proposal.)

Please confirm that you will be attending by responding to this email. You will 
also need to register for the event, at 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.apachecon.com%2Facah2021%2Fregister.htmldata=04%7C01%7Cgregoryg%40vmware.com%7C195452c8c4544b1c596208d9371651ae%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637601391271000992%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=QNyhxysm3tko%2BfceiNAmBMJGy4KFbGXPRVrBkWNu0pQ%3Dreserved=0,
 in order to be able to give your presentation. Please do not put this off, as 
that will make the scheduling process more difficult - please go do that now. 
Thanks.

With regards,
The team behind ApacheCon 2021



-
Gregory Green | Advisor Solution Engineer | Tanzu Data 
Mobile: 732.737.7119| Email: grego...@vmware.com 
--
Articles/Videos
Monoliths to Microservices? Don’t Forget to Transform the Data Layer 

A Caching Approach to Data Transformation of Legacy RDBMS 

How to Build Modern Data Pipelines with GemFire and SCDF 

GemFire AWS Quickstart 
 
 

On 4/23/21, 11:03 AM, "Rich Bowen"  wrote:

[You are receiving this because you're subscribed to one or more dev@
mailing lists for an Apache project, or the ApacheCon Announce list.]

Time is running out to submit your talk for ApacheCon 2021.

The Call for Presentations for ApacheCon @Home 2021, focused on Europe
and North America time zones, closes May 3rd, and is at

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.apachecon.com%2Facah2021%2Fcfp.htmldata=04%7C01%7Cgregoryg%40vmware.com%7Ccc707c5c26394c97c38f08d90668fc34%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637547870269279991%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=%2FssIougp2FOWef7HroIfOwMi7f6ypSgAXNjapZUCZpM%3Dreserved=0

The CFP for ApacheCon Asia, focused on Asia/Pacific time zones, is at

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapachecon.com%2Facasia2021%2Fcfp.htmldata=04%7C01%7Cgregoryg%40vmware.com%7Ccc707c5c26394c97c38f08d90668fc34%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637547870269279991%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=%2B4eqBNgkJIAVLNtZNgzYQd%2FkpPEJgh2tDXnlJNFFWNs%3Dreserved=0
 and also closes on May 3rd.

ApacheCon is our main event, featuring content from any and all of our
projects, and is your best opportunity to get your project in front of
the largest audience of enthusiasts.

Please don't wait for the last minute. Get your talks in today!

-- 
Rich Bowen, VP Conferences
The Apache Software Foundation

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapachecon.com%2Fdata=04%7C01%7Cgregoryg%40vmware.com%7Ccc707c5c26394c97c38f08d90668fc34%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637547870269279991%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=MVHWG69GbmTDdKKQWyScrj3HLzcTz7DtnQwJ3C4fYes%3Dreserved=0
@apachecon