Re: [DISCUSS] Backporting to support branches

[Nabarun Nag]

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

[DISCUSS] Backporting to support branches

[Nabarun Nag]

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] Cutting a Geode 1.14.0 release branch

[Owen Nichols]

Weeks since support/1.14 cut:  5
Changes backported this week:  7
Blockers we are still waiting on:  8

As of today I am no longer serving as Geode 1.14 Release Manager.  Please 
volunteer if you would like to take over.

On 3/12/21, 3:09 PM, "Owen Nichols"  wrote:

Weeks since support/1.14 cut:  4
Blockers backported this week:  9
Blockers we are still waiting on:  9

If there's anything else we should be waiting on, please make a proposal to 
add it to the blocker board sooner rather than later (even if you're still 
investigating...fix doesn't have to be fully ready yet, but do please update in 
the ticket how it is progressing for anything taking "longer than a week")

On 3/5/21, 6:02 PM, "Owen Nichols"  wrote:

It's been three weeks since support/1.14 was cut.  This week, backports 
for 12 blockers arrived on support/1.14.  Great job!

As of now, the blocker board [1] shows that we are waiting on 9 
blockers.  Once this list reaches zero, I can prepare RC1.

[1] 
https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12336052

On 2/26/21, 9:09 AM, "Owen Nichols"  wrote:

It's been two weeks since support/1.14 was cut, and the 1.14.0 
blocker board[1] still lists 5 issues (1 still Unassigned).  

Given the lack of activity on GEODE-8943, GEODE-8860, and 
GEODE-8809, should we defer them to 1.14.1 if we still "aim to ship on March 
12th."?

On 2/18/21, 10:00 AM, "Owen Nichols"  wrote:

It's been about a week since support/1.14 was cut, and the 
1.14.0 blocker board [1] still lists 5 issues (two of which appear to be 
Unassigned).  If a fix is taking longer than expected, please consider posting 
a status update in the ticket about once a week, and ask for help on the dev 
list if you need.

On 2/12/21, 1:20 AM, "Owen Nichols"  wrote:

support/1.14 has been cut.  Any fixes on develop from today 
onward should be marked as Fixed In 1.15.0.

The 1.14.0 blocker board [1] currently lists 5 issues.  RC1 
won't be created before this list gets to zero.  To add to the blocker board, 
please propose on the dev list.


On 2/10/21, 8:49 AM, "Owen Nichols"  
wrote:

Sounds good.

Once cut, only fixes from the blocker board may be 
brought to support/1.14.

After Feb 12, if you wish to add a critical issue to 
the blocker board, please propose it on the dev list.  If the community agrees 
it is critical, you may tag it as "blocks-1.14.0"

Thanks,
Owen Nichols
1.14.0 Release Manager

On 2/9/21, 11:54 AM, "Alexander Murmann" 
 wrote:

Hi everyone,

We aren't seeing many issues that would prevent a 
1.14.0 release on our blocker board < 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fsecure%2FDashboard.jspa%3FselectPageId%3D12336052&data=04%7C01%7Conichols%40vmware.com%7C044e0f6d6c40402fc5be08d8e5abe499%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637511873737999028%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9U038uieMzHb%2B%2B1%2FVL8SsnGSMN7pzIEQCI0WdkkqNRA%3D&reserved=0>
 and all issues have an owner. No new issues seem to be coming in either. This 
seems like a good time to finally cut a 1.14 release branch and get us on track 
to ship Apache Geode 1.14.0 in early March.

I propose we cut the branch at the end of this week 
and aim to ship 4 weeks later, on March 12th.

Re: PROPOSAL: Backport GEODE-9044 - Introduce RedisKey as key object for RedisData entries

[Jens Deppe]

Sorry, I forgot to add that this proposal is to backport to 1.14.0

On 3/19/21, 7:35 AM, "Jens Deppe"  wrote:

This work builds on GEODE-9023 which added sharding support to the 
compatible with Redis region.

This change cleans up data structures and will allow for easier, future 
rolling upgrades and data migrations if necessary.

Thanks
--Jens

Re: PROPOSAL: Backport GEODE-9044 - Introduce RedisKey as key object for RedisData entries

[Joris Melchior]

+1

On 2021-03-19, 10:35 AM, "Jens Deppe"  wrote:

This work builds on GEODE-9023 which added sharding support to the 
compatible with Redis region.

This change cleans up data structures and will allow for easier, future 
rolling upgrades and data migrations if necessary.

Thanks
--Jens

Re: PROPOSAL: Backport GEODE-9044 - Introduce RedisKey as key object for RedisData entries

[Nabarun Nag]

+1

Get Outlook for iOS

From: Jens Deppe 
Sent: Friday, March 19, 2021 7:35:03 AM
To: dev@geode.apache.org 
Subject: PROPOSAL: Backport GEODE-9044 - Introduce RedisKey as key object for 
RedisData entries

This work builds on GEODE-9023 which added sharding support to the compatible 
with Redis region.

This change cleans up data structures and will allow for easier, future rolling 
upgrades and data migrations if necessary.

Thanks
--Jens

PROPOSAL: Backport GEODE-9044 - Introduce RedisKey as key object for RedisData entries

[Jens Deppe]

This work builds on GEODE-9023 which added sharding support to the compatible 
with Redis region.

This change cleans up data structures and will allow for easier, future rolling 
upgrades and data migrations if necessary.

Thanks
--Jens