Release team meeting agenda 2022-03-16

Foreman 3.2

  • Status of GA release

Proposals to changes in the process:


  • Switch Katello repositories to be numbered based on the Foreman version

    • We don’t have decision, @ekohl mentioned about bumping Foreman and Katello to common version number 5.0 , maybe?
  • Gating nightly publishing of Foreman and Katello only if both Foreman and Katello pipelines are green

    • There is RFC about same proposal however there is no decision on same.
  • Removing anything “special” in Katello release process to map to Foreman

    • Align the redmine issue management as similar to Foreman. Specially the way Foreman uses Target Version' and Fixed in releases` fields. @ekohl initiated discussion about same with @iballou, like to know more about same.
    • The Katello’s release process talks extensively about the using tool_belt for cherry picks however Foreman does not, discussion on which works best?
    • The Katello uses tool_belt to check deprecation warnings, however Foreman process does not says to use that?
    • The Katello process has manual updates of changelog and tagging, however Foreman uses the script for same, maybe Katello can use the script as well?
    • The Foreman process uses the tarball however Katello release includes the Gem release, not something we can align to each other?
    • As per the process release engineer’s to do for Katello is less as most of the stuff is already handled in Foreman’s release?
  • Single branching procedure for all projects

  • Single release owner

  • Single release process


  • Actual release process should be effort of more than a day?
  • There should be co-owner for the branching and release processes?
    • If in case primary owner needs to take planned or unplanned leave? then handover will be smooth?
  • How to minimize the delays in planned and actual delivery date? Considering combined release process will need more efforts to be on time?
    • Should we plan the release on every Tuesday of the week and not on the specific date? As I see we miss the deadline often because of dependencies.
    • Do we need two individuals from delivery team to pull this off on time?
  • Need to define what should be common and what requires attention from respective teams?
    • The specific doc updates, like upgrade warnings, deprecation, headline features should be handled by respective teams?
    • The cherry-picks should be handled by respective teams.
1 Like

Foreman 3.2 GA:

  • Packaging from RPM and debian packages side is done

  • API docs are still pending amit is covering it

  • There is still an open PR for a documentation on modularity that is being worked on, but should be able to be finished today or tomorrow.

Katello 4.4 GA:

  • Cherry-picks have been started

  • A user brought forward some issues in 4.3 which would be problematic because 4.2 would go end of life, thus forcing more upgrades.

    • There are a couple of redmines that make having 4.4 GA problematic

    • Two Pulp Bugs that may need some attention from the team working on the installer

    • Because the issue for this would be in a foreman-installer issue we think it will be aligned to 3.2.1

Changes to process:

  • Switch katello repositories to share a version number with Foreman

    • General agreement that it seems like a net positive for both projects
  • Gating nightly publishing on both Foreman & Katello pipelines passing

    • Decided we needed more insight from other members to understand what the intracacies need to considered to change both of the pipelines
  • Katello process centered around tool_belt for cherry-picks.

    • @iballou reports tool-belt is fairly streamlined and seems to work well as is.

    • @upadhyeammit thinks that if that’s the case we should align to use tool-belt

    • upstream tool-belt needs to be checked for this to make sure foreman redmines are populated with the right data.


The most problematic Katello 4.3+ issues are discussed in the following threads:

1 Like