Skip to content

[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

Merged
merged 2 commits into from
Feb 5, 2024

Conversation

tstellar
Copy link
Collaborator

@tstellar tstellar commented Feb 2, 2024

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.

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.
@tstellar tstellar requested review from tru and nikic February 2, 2024 06:23
Copy link

github-actions bot commented Feb 2, 2024

✅ With the latest revision this PR passed the Python code formatter.

Copy link
Collaborator

@tru tru left a 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?

@tstellar
Copy link
Collaborator Author

tstellar commented Feb 2, 2024

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".

Copy link
Contributor

@nikic nikic left a 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).

@tstellar
Copy link
Collaborator Author

tstellar commented Feb 4, 2024

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.

@nikic
Copy link
Contributor

nikic commented Feb 4, 2024

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.

@tstellar tstellar merged commit 9805c05 into llvm:main Feb 5, 2024
agozillon pushed a commit to agozillon/llvm-project that referenced this pull request Feb 5, 2024
…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.
ichaer added a commit to ichaer/llvm-project-onesided_lower_bound that referenced this pull request Feb 12, 2024
* 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)
  ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants