You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[flutter release] strategy on better ways to merge cherry pick PR #145557
For the longest time I thought cherry pick author should be the one tuning the tests and merging the PR, but today I read https://github.com/flutter/flutter/wiki/Flutter-Cherrypick-Process and realized that it says "The release engineering team will merge the cherry-pick pull request"
In this week's release #145184 and flutter-team-archive/engine#51425 were merged by me, and I had to rerun tests and stamp LGTM on one of them. However, I didn't realize #145181 was also left open as a cherry pick PR and not merged.
Would it be possible to change the policy, so that PR authors are the one merging cherry pick PRs?
@XilaiZhang we have the automated cherry-pick action. Wouldn’t we rather just write another action that adds the autosubmit label once the approved label is added? This takes the burden off of both parties.
Yeah the 3 PRs aren't opened through the automated action because, one of them has a merge conflict, and the two others don't have a corresponding PR merged into main/master.
my understanding is that even if they are opened through automated cherry pick PR, if we submit based on approved status, then:
If author approves the bot PR, it can merge it without reviewer / TL approval
the tests could still be failing when approval is given, and autosubmit label would be removed.
if the cps are manually created, then it is also possible that:
approval is granted on cherry pick issue, but not granted on cherry pick PR.
If we are okay with the risks, I think submitting based on approval would resolve 1 of the 3 PRs from this week. Are we good with accepting the risks (mostly the potential of skipping TL review?)
from triage: still better to leave to release engineer to merge. not release engineer's fault if pr missed cutoff due to failed tests. kevin will kindly help update the wiki page.
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.
Activity
itsjustkevin commentedon Mar 22, 2024
@XilaiZhang we have the automated cherry-pick action. Wouldn’t we rather just write another action that adds the autosubmit label once the approved label is added? This takes the burden off of both parties.
XilaiZhang commentedon Mar 22, 2024
Yeah the 3 PRs aren't opened through the automated action because, one of them has a merge conflict, and the two others don't have a corresponding PR merged into main/master.
my understanding is that even if they are opened through automated cherry pick PR, if we submit based on approved status, then:
if the cps are manually created, then it is also possible that:
If we are okay with the risks, I think submitting based on approval would resolve 1 of the 3 PRs from this week. Are we good with accepting the risks (mostly the potential of skipping TL review?)
XilaiZhang commentedon Apr 3, 2024
from triage: still better to leave to release engineer to merge. not release engineer's fault if pr missed cutoff due to failed tests. kevin will kindly help update the wiki page.
github-actions commentedon Apr 17, 2024
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.