Improving the Foreman backporting process

Development RFCs
1

RFC: Improving the Foreman backporting process

Context and Problem Statement

The Foreman release process doesn’t well define how backports work. Today, developers often perform their own backports. There isn’t a defined Redmine triage process, so the “target version” cannot be relied on. This means that community contributors may have a hard time requesting backports of their code for a specific version of Foreman, and it also means that there is more work on the release engineer.

This issue came up in the PR https://github.com/theforeman/foreman/pull/11033#issuecomment-4889890256.

Proposal

There are a couple ideas that came up during today’s upstream release meeting:

  1. Have Foreman follow Katello’s release process. This would mean that core Foreman contributors need to perform consistent Redmine triages where the target version is set correctly. Then, a script at release time would tell the release owner which cherry picks to perform based on Redmine information.
  2. Introduce cherry pick labels in GitHub, similarly to how the Pulp and Robottelo projects keep track of what to backport. This could evolve into increased GitHub automation, like automated cherry-pick PRs, or better changelogs for releases within GitHub. This idea comes from @Odilhao, so I may have missed some intricacies.

Decision Outcome

…

Impacts

The ideas above have impacts on the amount of work that core Foreman maintainers need to perform, and also our use of Redmine versus GitHub for issue tracking.

Tagging @ogajduse and @Zhunting who were part of the meeting discussion that spawned this RFC.

4 Likes
Release Team Meeting 2026-07-15
2

One thing that is nice about labels on the PR, is that it makes it very visible on the PR itself. I reserve judgement on whether this conflicts with tickets being the main source of truth.

1 Like
3

I also like the label idea. But one question remains: Who decides what gets cherry-picked?

2 Likes
4

In Foreman today it seems to be mostly up to the contributor, so I think the GH labels idea would be continuing down that path without a core developer triage meeting like Katello. Perhaps, though, the CP request would be more visible on GH, which would get more conversation going around the CP request.