You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by "Jarek Potiuk (Jira)" <ji...@apache.org> on 2022/07/06 17:23:00 UTC
[jira] [Comment Edited] (LEGAL-599) Using GitHub's "Merge Queue" functionality
[ https://issues.apache.org/jira/browse/LEGAL-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17563339#comment-17563339 ]
Jarek Potiuk edited comment on LEGAL-599 at 7/6/22 5:22 PM:
------------------------------------------------------------
Could we please revise the statement here?
I think that really the "Merge Queue" approach does not change too much and especially not violate the "explicit act of commiter". We discussed recently how useful it would be to have it - because it would help a lot in Apache Airflow to handle ever growing number of PRs we get.
Why I think it does not violate the "explict act of commiter"?
Because adding the PR to "merge queue" is an "explicit act". How the process looks like currently
a) a contributor creates (or updates existing)pull request
b) tests are starting
c) in paralllel a commiter reviews the code
d) Committer gives approval
e) time passes (sometimes hours)
f) the build succeeds (hopefully)
g) committter comes back to it - DOUBLE checks if the code is the same as it was reviewed the last time (because this might be an hour or a day later when the tests succeeded and committer returned to it)
h) committer merges it
So far so good. A lot of back-forth, usually it means that committer has to have some list of things to remember about (or come back couple of hours later/next day to review all potentially mergable commits that passed the tests). With Merge Queue the workflow is different but "explicit act of committer" is there, only it is delayed until ALSO all tests pass:
a) a contributor creates (or updates existing)pull request
b) tests are starting
c) in paralllel a commiter reviews the code
d) Committer gives approval
h) committer adds the PR to "merge queue" <- this is the explicit act of committer
e) time passes (sometimes hours)
f) the build succeeds (hopefully)
g) the PR gets merged automatically without commiter having to remember about doing it
So all that actually changes, is the "act of commiter" will be effective only when test pass - so we have automation that gates materialising of the act conditionally "if tests pass". But this is one way street, NOTHING will happen if the committer does not do the "explicit act" AFTER reviewing it (i.e. adding to merge queue). Any action from contributor (like rebasing or modifying the PR) will remove the PR from the merge queue - effectively cancelling the "explicit act" - and the committer will have to do the "explicit act" once again if this happened.
Also recently we accepted the fact that Dependabot *{*}might{*}* create branches that then can be merged on explicit act of committer (Approval and Merge). This is the same kind of situation so I think there is no reason we should block it.
WDYT [~rvs] ?
was (Author: higrys):
Could we please revise the statement here?
I think what really the "Merge Queue" approach does not change too much and especially not violate the "explicit act of commiter". We discussed recently how useful it would be to have it - because it would help a lot in Apache Airflow to handle ever growing number of PRs we get.
Why I think it does not violate the "explict act of commiter"?
Because adding the PR to "merge queue" is an "explicit act". How the process looks like currently
a) a contributor creates (or updates existing)pull request
b) tests are starting
c) in paralllel a commiter reviews the code
d) Committer gives approval
e) time passes (sometimes hours)
f) the build succeeds (hopefully)
g) committter comes back to it - DOUBLE checks if the code is the same as it was reviewed the last time (because this might be an hour or a day later when the tests succeeded and committer returned to it)
h) committer merges it
So far so good. A lot of back-forth, usually it means that committer has to have some list of things to remember about (or come back couple of hours later/next day to review all potentially mergable commits that passed the tests). With Merge Queue the workflow is different but "explicit act of committer" is there, only it is delayed until ALSO all tests pass:
a) a contributor creates (or updates existing)pull request
b) tests are starting
c) in paralllel a commiter reviews the code
d) Committer gives approval
h) committer adds the PR to "merge queue" <- this is the explicit act of committer
e) time passes (sometimes hours)
f) the build succeeds (hopefully)
g) the PR gets merged automatically without commiter having to remember about doing it
So all that actually changes, is the "act of commiter" will be effective only when test pass - so we have automation that gates materialising of the act conditionally "if tests pass". But this is one way street, NOTHING will happen if the committer does not do the "explicit act" AFTER reviewing it (i.e. adding to merge queue). Any action from contributor (like rebasing or modifying the PR) will remove the PR from the merge queue - effectively cancelling the "explicit act" - and the committer will have to do the "explicit act" once again if this happened.
Also recently we accepted the fact that Dependabot **might** create branches that then can be merged on explicit act of committer (Approval and Merge). This is the same kind of situation so I think there is no reason we should block it.
WDYT [~rvs] ?
> Using GitHub's "Merge Queue" functionality
> ------------------------------------------
>
> Key: LEGAL-599
> URL: https://issues.apache.org/jira/browse/LEGAL-599
> Project: Legal Discuss
> Issue Type: Question
> Reporter: Martijn Visser
> Priority: Major
>
> Recently GitHub has announced the limited beta of their "Pull Request Merge Queue" functionality. More information can be found at https://github.blog/changelog/2021-10-27-pull-request-merge-queue-limited-beta/
> This seems like an interesting functionality for a lot of ASF projects, given that there are a lot of projects that have a high volume of changes from multiple users being merged every day. For example, the Apache Flink project is in this situation.
> This functionality does create temporary branches for the queues. Given the discussion around Dependabot, I'm wondering what the ASF thinks of this feature and if it could potentially be enabled for ASF projects. For context, I've opened https://issues.apache.org/jira/browse/LEGAL-589 last month to get clarification on Dependabot and creating branches in ASF repos. Given that resolution, I would expect that this functionality could also be allowed under the same conditions, but I wanted to get confirmation from Legal upfront.
> (Note: I've posted this question in November on the users@infra.apache.org mailing list. There are other ASF projects who are also interested in this.)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org