Release Team Meeting 2026-03-04

Development Releases
1

Release Team Meeting 2026-03-04

Meeting Type: Foreman Release Team Meeting
Date: March 4, 2026
Community: https://community.theforeman.org

Foreman Nightly

Foreman 3.18

Foreman 3.17

Foreman 3.16

Katello 4.20

Katello 4.19

Pulp Integration

  • Current Status
    • pulp_deb 3.8 update
    • We need to fix pulp-deb
    • Katello 4.21 to be updated to pulpcore 3.103
      • We’ll need new Postgres with 3.103 because of Django
    • We don’t know when Pulp 4 is going to be released, yet (Django 5)
    • We can’t update to past Postgres 13 at the moment, most likely due to Candlepin??
2

@jeremylenz @iballou, we also discussed updating Candlepin in this meeting. The fact that we updated Candlepin for Katello 4.20 that late in the release process caught my attention.

Is the following order of actions correct?

  1. Candlepin (people/group/team) releases a new version - either a major or minor one
  2. Candlepin notifies, or Katello is notified about the new release
  3. Katello makes sure they’re ready for the new Candlepin version
  4. Katello asks Foreman release engineers to package and release the new version of Candlepin
3

Those seem correct to me. Typically we’d tag it into nightly first, and Candlepin will do separate Candlepin releases for each version needing backport. cc @nikos_moum

4

That’s my understanding as well

5

Now that we’ve cleared that up, I’d like to discuss how we can ensure Candlepin updates are better synchronized with the Foreman development cycle—ideally, well before a release is branched.

The 3.18/4.20 cycle was a perfect example of why the current ‘ad-hoc’ approach is risky. We saw Candlepin bumped from 4.6 to 4.7 between RC2 and GA, primarily driven by a specific fix (SAT-42216). Because this wasn’t coordinated through the release team (JPL):

  • Visibility was low: The release team only became aware of the version jump after it was already being tagged into streams.
  • Timing was off: The bump occurred two days after the Foreman 3.18 branch was created.

As a release owner, being pulled in at ‘Step 4’ (after the decision and initial PRs are made) puts rel-eng in a reactive position. Jeremy even mentioned not being sure what the specific steps were to make the backports happen upstream.

Can we move the release team’s involvement to Step 1 or 2? If we are involved when the need for a new Candlepin version is first identified, we can:

  1. Ensure the packaging steps are handled correctly to avoid breaking nightly.
  2. Align the bump with the branching schedule rather than chasing it during the RC phase.
  3. Provide the necessary guidance to contributors on the upstream/downstream flow.

Alternatively, should we implement automated watchers for new Candlepin releases so the release team isn’t relying solely on manual pings?

Thoughts?