Open DanHeidinga opened 4 years ago
And to further the 'low-cost' aspect of this, we could leverage github actions to trigger testing or other activities that need to be done against a branch, based on a label event (or any other github event for that matter). Be aware that while there are only limited platforms available as runners, that there are github actions that would allow you to trigger Jenkins jobs (so leveraging our existing pipelines, but keeping it very transparent in a workflow file to trigger branch-based testing).
Pulling this comment out into a new issue as the basis for a plan on how to handle backports for the interim release proposal.
Will close this issue if the proposal fails to gain acceptance.
Labels would work pretty good for this. There's already a
backport:candidate
label that could be added when a PR is merged inmaster
. Once a backport is agreed on, we could add abackport:accepted
, and maybe abackport:complete
label after the backport is merged? And maybe abackport:rejected
label for cases where we decided not to backport.There should be a fairly low cost workflow that can be implemented with labels and maybe if we want to get really fancy, a new
backports
project kanban board.Originally posted by @DanHeidinga in https://github.com/eclipse/openj9/issues/9316#issuecomment-619984772