You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Owen Nichols <on...@vmware.com> on 2021/06/29 22:51:45 UTC
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" <nn...@vmware.com> 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 <nn...@vmware.com>
Sent: Friday, March 19, 2021 10:31 AM
To: dev@geode.apache.org <de...@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
Posted by Nabarun Nag <nn...@vmware.com>.
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 <ja...@vmware.com>
Sent: Tuesday, June 29, 2021 4:44 PM
To: dev@geode.apache.org <de...@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 <nn...@vmware.com> 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 <on...@vmware.com>
> Sent: Tuesday, June 29, 2021 3:51 PM
> To: dev@geode.apache.org <de...@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" <nn...@vmware.com> 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 <nn...@vmware.com>
> Sent: Friday, March 19, 2021 10:31 AM
> To: dev@geode.apache.org <de...@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
Posted by Jacob Barrett <ja...@vmware.com>.
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 <nn...@vmware.com> 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 <on...@vmware.com>
> Sent: Tuesday, June 29, 2021 3:51 PM
> To: dev@geode.apache.org <de...@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" <nn...@vmware.com> 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 <nn...@vmware.com>
> Sent: Friday, March 19, 2021 10:31 AM
> To: dev@geode.apache.org <de...@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
Posted by Nabarun Nag <nn...@vmware.com>.
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 <on...@vmware.com>
Sent: Tuesday, June 29, 2021 3:51 PM
To: dev@geode.apache.org <de...@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" <nn...@vmware.com> 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 <nn...@vmware.com>
Sent: Friday, March 19, 2021 10:31 AM
To: dev@geode.apache.org <de...@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