During our pulpcore meeting, we recognized that the process of committing fixes to release branches (ie backporting) was completely manual and cumbersome. We identified patchback as a possible tool we could use to automate our backport process. I think we could use this tool but we’d have to make some changes to our backporting process.
Patchback
Patchback is a github bot which can automatically open cherry pick PRs with changes to release branches. This would involve definining a config and then labeling PRs with the appropriate label (see https://github.com/ansible/galaxy_ng/pull/858#event-5308638474 as an example). After that, patchback will automatically open a PR with the change against the release branch (see https://github.com/ansible/galaxy_ng/pull/968).
Changing our Backport Process
We would need to modify our backport and release processes in order to use patchback. I think these changes would suffice:
- Keep cherry pick commits attached to the original issues instead of reattaching them to their respective backport request.
- Disable the checking of issue statuses in the CI for PRs/commits against release branches.
- Update the release automation to no longer fail/update any issue if it is already attached to a different milestone.
I believe that these changes should allow us to use patchback. The one shortcoming is that milestones in redmine wouldn’t necessary contain all the issues in the release. But we could use the changelog as the canonical list of changes in a release.
Questions
- What do we do with backport tracker type in redmine?
- Get rid of it? How do stakeholders request backports?
- Who is responsible for setting the labels for PRs?
- We could potentially automate this.
- Who handles failed cherry picks?