date:20210629

Re: [DISCUSS] Backporting to support branches

2021-06-29 Thread Nabarun Nag

This was done to reduce the workload on the developers.
It's a kind of "fire and forget" methodology.
Why make the author come back and merge the PR after my(release manager's) 
approval when I can do it myself.

But yeah, blocking the PR, till the release manager approves it makes sense.


Regards
Nabarun


From: Jacob Barrett 
Sent: Tuesday, June 29, 2021 4:44 PM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Backporting to support branches

Why not a model where the release manager is a blocking review and let the 
author merge only when they blocking review is complete? That makes the process 
largely identical to that of the develop branch abs removes this ambiguity of 
who merges and when.

> On Jun 29, 2021, at 4:19 PM, Nabarun Nag  wrote:
>
> I just do the merging to have a sanitized and approved list of PRs go into 
> the support/1.14. Limit the number of commits that may cause an explosion.
>
> Also, I communicate with the author about PR, if it is ready to be merged or 
> if I have concerns about the PR.
>
> I will not merge your PR but feel free to ping me when all your testing is 
> done and then I will take the necessary steps.
>
> Regards,
> Nabarun
> 
> From: Owen Nichols 
> Sent: Tuesday, June 29, 2021 3:51 PM
> To: dev@geode.apache.org 
> Subject: Re: [DISCUSS] Backporting to support branches
>
> Hi Naba, is it still the case that only you will merge the PRs to 
> support/1.14?  Or can committers merge their own 1.14 PRs anytime after you 
> have approved the PR?
>
> I sometimes forget to create my PRs in Draft mode, and may still be running 
> additional tests, so I'd prefer not to have anyone but me merging my PR.
>
> On 3/19/21, 10:47 AM, "Nabarun Nag"  wrote:
>
>Just a small change, a PR against the support branch is enough. (No need 
> to add reviewers etc.). I just realized we can filter on a branch in the PR 
> list.
>
>Regards,
>Nabarun
>
>From: Nabarun Nag 
>Sent: Friday, March 19, 2021 10:31 AM
>To: dev@geode.apache.org 
>Subject: [DISCUSS] Backporting to support branches
>
>Hi,
>
>I would like to propose that if any JIRA needs to be backported to support 
> branches:
>
>For Developers:
>
>  *   Add the label "blocks-1.1x" to the JIRA ticket
>  *   There is no need to send out a PROPOSAL email to dev
>  *   Just create the cherry-picked  PR to the support branch and tag the 
> Release Manager as a reviewer or just tag in the comments section if you are 
> not a committer. (ensure no merge conflicts)
>
>NOTE: Ensure that the commit you are trying to backport is already merged 
> into develop. Also, the PR against the support branch needs to be a cherry 
> pick. (git cherry-pick -x)
>
>For Release Manager:
>
>  *   Monitor the release dashboard for "blocks-1.1x" tickets
>  *   Send out communications if there are any issues.
>  *   Squash-merge the PR if it the commit message is properly structured 
> with cherry pick message in the last line.
>
>Regards
>Nabarun
>
>
>
>

Re: [DISCUSS] Backporting to support branches

2021-06-29 Thread Jacob Barrett

Why not a model where the release manager is a blocking review and let the 
author merge only when they blocking review is complete? That makes the process 
largely identical to that of the develop branch abs removes this ambiguity of 
who merges and when.

> On Jun 29, 2021, at 4:19 PM, Nabarun Nag  wrote:
> 
> I just do the merging to have a sanitized and approved list of PRs go into 
> the support/1.14. Limit the number of commits that may cause an explosion.
> 
> Also, I communicate with the author about PR, if it is ready to be merged or 
> if I have concerns about the PR.
> 
> I will not merge your PR but feel free to ping me when all your testing is 
> done and then I will take the necessary steps.
> 
> Regards,
> Nabarun
> 
> From: Owen Nichols 
> Sent: Tuesday, June 29, 2021 3:51 PM
> To: dev@geode.apache.org 
> Subject: Re: [DISCUSS] Backporting to support branches
> 
> Hi Naba, is it still the case that only you will merge the PRs to 
> support/1.14?  Or can committers merge their own 1.14 PRs anytime after you 
> have approved the PR?
> 
> I sometimes forget to create my PRs in Draft mode, and may still be running 
> additional tests, so I'd prefer not to have anyone but me merging my PR.
> 
> On 3/19/21, 10:47 AM, "Nabarun Nag"  wrote:
> 
>Just a small change, a PR against the support branch is enough. (No need 
> to add reviewers etc.). I just realized we can filter on a branch in the PR 
> list.
> 
>Regards,
>Nabarun
>
>From: Nabarun Nag 
>Sent: Friday, March 19, 2021 10:31 AM
>To: dev@geode.apache.org 
>Subject: [DISCUSS] Backporting to support branches
> 
>Hi,
> 
>I would like to propose that if any JIRA needs to be backported to support 
> branches:
> 
>For Developers:
> 
>  *   Add the label "blocks-1.1x" to the JIRA ticket
>  *   There is no need to send out a PROPOSAL email to dev
>  *   Just create the cherry-picked  PR to the support branch and tag the 
> Release Manager as a reviewer or just tag in the comments section if you are 
> not a committer. (ensure no merge conflicts)
> 
>NOTE: Ensure that the commit you are trying to backport is already merged 
> into develop. Also, the PR against the support branch needs to be a cherry 
> pick. (git cherry-pick -x)
> 
>For Release Manager:
> 
>  *   Monitor the release dashboard for "blocks-1.1x" tickets
>  *   Send out communications if there are any issues.
>  *   Squash-merge the PR if it the commit message is properly structured 
> with cherry pick message in the last line.
> 
>Regards
>Nabarun
> 
> 
> 
>

Re: [DISCUSS] Backporting to support branches

2021-06-29 Thread Nabarun Nag

I just do the merging to have a sanitized and approved list of PRs go into the 
support/1.14. Limit the number of commits that may cause an explosion.

Also, I communicate with the author about PR, if it is ready to be merged or if 
I have concerns about the PR.

I will not merge your PR but feel free to ping me when all your testing is done 
and then I will take the necessary steps.

Regards,
Nabarun

From: Owen Nichols 
Sent: Tuesday, June 29, 2021 3:51 PM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Backporting to support branches

Hi Naba, is it still the case that only you will merge the PRs to support/1.14? 
 Or can committers merge their own 1.14 PRs anytime after you have approved the 
PR?

I sometimes forget to create my PRs in Draft mode, and may still be running 
additional tests, so I'd prefer not to have anyone but me merging my PR.

On 3/19/21, 10:47 AM, "Nabarun Nag"  wrote:

Just a small change, a PR against the support branch is enough. (No need to 
add reviewers etc.). I just realized we can filter on a branch in the PR list.

Regards,
Nabarun

From: Nabarun Nag 
Sent: Friday, March 19, 2021 10:31 AM
To: dev@geode.apache.org 
Subject: [DISCUSS] Backporting to support branches

Hi,

I would like to propose that if any JIRA needs to be backported to support 
branches:

For Developers:

  *   Add the label "blocks-1.1x" to the JIRA ticket
  *   There is no need to send out a PROPOSAL email to dev
  *   Just create the cherry-picked  PR to the support branch and tag the 
Release Manager as a reviewer or just tag in the comments section if you are 
not a committer. (ensure no merge conflicts)

NOTE: Ensure that the commit you are trying to backport is already merged 
into develop. Also, the PR against the support branch needs to be a cherry 
pick. (git cherry-pick -x)

For Release Manager:

  *   Monitor the release dashboard for "blocks-1.1x" tickets
  *   Send out communications if there are any issues.
  *   Squash-merge the PR if it the commit message is properly structured 
with cherry pick message in the last line.

Regards
Nabarun

Re: [DISCUSS] Backporting to support branches

2021-06-29 Thread Owen Nichols

Hi Naba, is it still the case that only you will merge the PRs to support/1.14? 
 Or can committers merge their own 1.14 PRs anytime after you have approved the 
PR?

I sometimes forget to create my PRs in Draft mode, and may still be running 
additional tests, so I'd prefer not to have anyone but me merging my PR.

On 3/19/21, 10:47 AM, "Nabarun Nag"  wrote:

Just a small change, a PR against the support branch is enough. (No need to 
add reviewers etc.). I just realized we can filter on a branch in the PR list.

Regards,
Nabarun

From: Nabarun Nag 
Sent: Friday, March 19, 2021 10:31 AM
To: dev@geode.apache.org 
Subject: [DISCUSS] Backporting to support branches

Hi,

I would like to propose that if any JIRA needs to be backported to support 
branches:

For Developers:

  *   Add the label "blocks-1.1x" to the JIRA ticket
  *   There is no need to send out a PROPOSAL email to dev
  *   Just create the cherry-picked  PR to the support branch and tag the 
Release Manager as a reviewer or just tag in the comments section if you are 
not a committer. (ensure no merge conflicts)

NOTE: Ensure that the commit you are trying to backport is already merged 
into develop. Also, the PR against the support branch needs to be a cherry 
pick. (git cherry-pick -x)

For Release Manager:

  *   Monitor the release dashboard for "blocks-1.1x" tickets
  *   Send out communications if there are any issues.
  *   Squash-merge the PR if it the commit message is properly structured 
with cherry pick message in the last line.

Regards
Nabarun

Re: [Suspected Spam] [VOTE] Apache Geode 1.12.3.RC3

2021-06-29 Thread Dave Barnes

+1
User Guide build scripts are broken, but this is a known bug and should not
delay the release.
A compiled 1.12 User Guide is available on the website, and a knowledgeable
user can build manually as a workaround.
I have back-ported the fix to 1.12 from 1.13, so in the event of a new
release candidate or new 1.12.x patch release, the problem will no longer
exist.

On Mon, Jun 28, 2021 at 11:00 PM Nabarun Nag  wrote:

> +1 based on the following:
>
>   *   build from source
>   *   running gfsh
>   *   starting 2 site WAN cluster
>   *   verifying data propagation from the 2 sites using puts and gets
>   *   Rolling clusters from 1.12 to the release candidate.
>   *   Rebalance operations during upgrades.
>
>
> 
> From: Owen Nichols 
> Sent: Friday, June 25, 2021 1:15 PM
> To: dev@geode.apache.org 
> Subject: [Suspected Spam] [VOTE] Apache Geode 1.12.3.RC3
>
> Hello Geode Dev Community,
>
> I'd like to propose a 1.12 patch release.
>
> This is a release candidate for Apache Geode version 1.12.3.RC3.
> Note: This is the first vote email due to a build issue with the first two
> RCs.
> Thanks to all the community members for their contributions to this
> release!
>
> Please do a review and give your feedback, including the checks you
> performed.
>
> Voting deadline:
> 3PM PDT Wed, June 30 2021.
>
> Please note that we are voting upon the source tag:
> rel/v1.12.3.RC3
>
> Release notes:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.12.3data=04%7C01%7Cnnag%40vmware.com%7Ce430c96afebf48ee4afa08d938160689%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637602489520416316%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=HS9vNQnqaQ61%2F6t6dS%2F5A8DxugClKwc%2BrJMXnaLVs7Q%3Dreserved=0
>
> Source and binary distributions:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.12.3.RC3%2Fdata=04%7C01%7Cnnag%40vmware.com%7Ce430c96afebf48ee4afa08d938160689%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637602489520416316%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=56Fa2%2BC%2Bv2uCLxa6iRchEynUS%2B6OZAspwmwXzsya4eM%3Dreserved=0
>
> Maven staging repo:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1084data=04%7C01%7Cnnag%40vmware.com%7Ce430c96afebf48ee4afa08d938160689%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637602489520416316%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=iqjfSfVDYzuaj%2FzJs8YRLedEGBmI%2Fr4xTLFWMgRqzEg%3Dreserved=0
>
> GitHub:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.12.3.RC3data=04%7C01%7Cnnag%40vmware.com%7Ce430c96afebf48ee4afa08d938160689%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637602489520416316%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=KLkcUfgn1ZkXB6OBwOVzkECUCd1xU7YZWd1mc%2FZAlIU%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.12.3.RC3data=04%7C01%7Cnnag%40vmware.com%7Ce430c96afebf48ee4afa08d938160689%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637602489520416316%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=AQ8H4jHhSPm9f9evixDBNQJdJl0cWLOwGey8%2BkSf9Y0%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.12.3.RC3data=04%7C01%7Cnnag%40vmware.com%7Ce430c96afebf48ee4afa08d938160689%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637602489520416316%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=8IykbiM2prxCQ1tMM%2Ft15gryVmvc6jUFjegwplbBxGw%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.12.3.RC3data=04%7C01%7Cnnag%40vmware.com%7Ce430c96afebf48ee4afa08d938160689%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637602489520416316%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Gxw%2FT0BQPjiOmjlR8Sv4jwGj0wm8Z%2BSW4FUUnBQh8QE%3Dreserved=0
>
> Pipelines:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-12-maindata=04%7C01%7Cnnag%40vmware.com%7Ce430c96afebf48ee4afa08d938160689%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637602489520416316%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=y6ln0WC5b%2BVKdgIOR6W%2BLTbI4IUhG0p0u1A8YiqhDdk%3Dreserved=0
>
>

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

2021-06-29 Thread Nabarun Nag

Looking at the positive feedback, to this, I am skipping the red tape of 
creating a separate vote thread. The PR has been created and reviewed.[1]

Regards,
Nabarun

[1] https://github.com/apache/geode/pull/6661

From: Darrel Schneider 
Sent: Tuesday, June 29, 2021 9:13 AM
To: dev@geode.apache.org 
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop

+1

From: Jens Deppe 
Sent: Tuesday, June 29, 2021 7:44 AM
To: dev@geode.apache.org 
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop

+1 For Naba’s proposal

From: Joris Melchior 
Date: Tuesday, June 29, 2021 at 7:40 AM
To: dev@geode.apache.org 
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
+1 for Naburan’s proposed options.

From: Nabarun Nag 
Date: Monday, June 28, 2021 at 4: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

2021-06-29 Thread Darrel Schneider

+1

From: Jens Deppe 
Sent: Tuesday, June 29, 2021 7:44 AM
To: dev@geode.apache.org 
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop

+1 For Naba’s proposal

From: Joris Melchior 
Date: Tuesday, June 29, 2021 at 7:40 AM
To: dev@geode.apache.org 
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
+1 for Naburan’s proposed options.

From: Nabarun Nag 
Date: Monday, June 28, 2021 at 4: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

2021-06-29 Thread Jens Deppe

+1 For Naba’s proposal

From: Joris Melchior 
Date: Tuesday, June 29, 2021 at 7:40 AM
To: dev@geode.apache.org 
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
+1 for Naburan’s proposed options.

From: Nabarun Nag 
Date: Monday, June 28, 2021 at 4: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

2021-06-29 Thread Joris Melchior

+1 for Naburan’s proposed options.

From: Nabarun Nag 
Date: Monday, June 28, 2021 at 4: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: [Suspected Spam] [VOTE] Apache Geode 1.12.3.RC3

2021-06-29 Thread Nabarun Nag

+1 based on the following:

  *   build from source
  *   running gfsh
  *   starting 2 site WAN cluster
  *   verifying data propagation from the 2 sites using puts and gets
  *   Rolling clusters from 1.12 to the release candidate.
  *   Rebalance operations during upgrades.



From: Owen Nichols 
Sent: Friday, June 25, 2021 1:15 PM
To: dev@geode.apache.org 
Subject: [Suspected Spam] [VOTE] Apache Geode 1.12.3.RC3

Hello Geode Dev Community,

I'd like to propose a 1.12 patch release.

This is a release candidate for Apache Geode version 1.12.3.RC3.
Note: This is the first vote email due to a build issue with the first two RCs.
Thanks to all the community members for their contributions to this release!

Please do a review and give your feedback, including the checks you performed.

Voting deadline:
3PM PDT Wed, June 30 2021.

Please note that we are voting upon the source tag:
rel/v1.12.3.RC3

Release notes:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.12.3data=04%7C01%7Cnnag%40vmware.com%7Ce430c96afebf48ee4afa08d938160689%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637602489520416316%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=HS9vNQnqaQ61%2F6t6dS%2F5A8DxugClKwc%2BrJMXnaLVs7Q%3Dreserved=0

Source and binary distributions:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.12.3.RC3%2Fdata=04%7C01%7Cnnag%40vmware.com%7Ce430c96afebf48ee4afa08d938160689%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637602489520416316%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=56Fa2%2BC%2Bv2uCLxa6iRchEynUS%2B6OZAspwmwXzsya4eM%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1084data=04%7C01%7Cnnag%40vmware.com%7Ce430c96afebf48ee4afa08d938160689%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637602489520416316%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=iqjfSfVDYzuaj%2FzJs8YRLedEGBmI%2Fr4xTLFWMgRqzEg%3Dreserved=0

GitHub:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.12.3.RC3data=04%7C01%7Cnnag%40vmware.com%7Ce430c96afebf48ee4afa08d938160689%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637602489520416316%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=KLkcUfgn1ZkXB6OBwOVzkECUCd1xU7YZWd1mc%2FZAlIU%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.12.3.RC3data=04%7C01%7Cnnag%40vmware.com%7Ce430c96afebf48ee4afa08d938160689%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637602489520416316%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=AQ8H4jHhSPm9f9evixDBNQJdJl0cWLOwGey8%2BkSf9Y0%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.12.3.RC3data=04%7C01%7Cnnag%40vmware.com%7Ce430c96afebf48ee4afa08d938160689%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637602489520416316%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=8IykbiM2prxCQ1tMM%2Ft15gryVmvc6jUFjegwplbBxGw%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.12.3.RC3data=04%7C01%7Cnnag%40vmware.com%7Ce430c96afebf48ee4afa08d938160689%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637602489520416316%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Gxw%2FT0BQPjiOmjlR8Sv4jwGj0wm8Z%2BSW4FUUnBQh8QE%3Dreserved=0

Pipelines:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-12-maindata=04%7C01%7Cnnag%40vmware.com%7Ce430c96afebf48ee4afa08d938160689%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637602489520416316%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=y6ln0WC5b%2BVKdgIOR6W%2BLTbI4IUhG0p0u1A8YiqhDdk%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-12-rcdata=04%7C01%7Cnnag%40vmware.com%7Ce430c96afebf48ee4afa08d938160689%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637602489520416316%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=LO4BQWVFjjGKOUX1XPEIEwT98PGtzPyCCS07mn2dCTU%3Dreserved=0

Geode's KEYS file containing PGP keys we use to sign the release:

Re: [DISCUSS] Backporting to support branches

Re: [DISCUSS] Backporting to support branches

Re: [DISCUSS] Backporting to support branches

Re: [DISCUSS] Backporting to support branches

Re: [Suspected Spam] [VOTE] Apache Geode 1.12.3.RC3

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

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

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

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

Re: [Suspected Spam] [VOTE] Apache Geode 1.12.3.RC3

10 matches

Site Navigation

Mail list logo

Footer information