-
Notifications
You must be signed in to change notification settings - Fork 14.1k
[workflows] Close issues used for backports once the PR has been created #80394
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This will allow us to track the state of the backport request in the PR, rather than in the issue. The state updates for PRs can be automated, so this will save us some triage work.
✅ With the latest revision this PR passed the Python code formatter. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, before we have had the issue open until we had merged the PR. In case some of the needs some further discussion and revisions. Should we just do those comments and revisions directly in the PR going forward?
Yes, I was thinking we should try to push all the discussions to the PR, because that is where all the other activity is happening for the most part (e.g. patch gets reviewed, patch gets tested, patch gets merged) The alternative would be to add a new status to the LLVM release status project called "PR Created". In this case, we would leave the issue open and assign it this new "PR Created" status. Then the other statuses would be tracked only on the PR: e.g."Needs Review", "Needs Merged". |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this makes sense. In the future we might want to avoid creating issues in the first place and e.g. accept the cherry-pick command inside PRs (so you can directly run it in the PR that fixed the issue).
I think you can already use the cherry-pick command inside of PRs, because PR comments also generate the issue_comment event. |
An issue with that is that you would have to add the PR to the milestone first, even though it really shouldn't be part of it. |
…ted (llvm#80394) This will allow us to track the state of the backport request in the PR, rather than in the issue. The state updates for PRs can be automated, so this will save us some triage work.
* llvm/main: (328 commits) [Flang][OpenMP] Attempt to make map-types-and-sizes.f90 test more agnostic to other architectures [Transforms] Add more cos combinations to SimplifyLibCalls and InstCombine (llvm#79699) [workflows] Close issues used for backports once the PR has been created (llvm#80394) [RISCV] Add support for RISC-V Pointer Masking (llvm#79929) [lldb] Cleanup regex in libcxx formatters (NFC) (llvm#80618) [lldb] Remove unused private TypeCategoryMap methods (NFC) (llvm#80602) [mlir][sparse] refine sparse assembler strategy (llvm#80521) [NFC] Fix typo (llvm#80703) Fix broken ARM processor features test (llvm#80717) [ValueTracking][NFC] Pass `SimplifyQuery` to `computeKnownFPClass` family (llvm#80657) [x86_64][windows][swift] do not use Swift async extended frame for wi… (llvm#80468) [X86] addConstantComments - add FP16 MOVSH asm comments support [X86] Regenerate some vector constant comments missed in recent patches to improve mask predicate handling in addConstantComments [clang][AMDGPU][CUDA] Handle __builtin_printf for device printf (llvm#68515) Add some clarification to email check message [GitHub][Workflows] Prevent multiple private email comments (temporarily) (llvm#80648) [workflows] Use /mnt as the build directory on Linux (llvm#80583) [Flang][OpenMP] Initial mapping of Fortran pointers and allocatables for target devices (llvm#71766) [AMDGPU] GlobalISel for f8 conversions (llvm#80503) [AMDGPU] Fixed byte_sel of v_cvt_f32_bf8/v_cvt_f32_fp8 (llvm#80502) ...
This will allow us to track the state of the backport request in the PR, rather than in the issue. The state updates for PRs can be automated, so this will save us some triage work.