Release team meeting agenda 20220-03-09

[ehelms]

Foreman

• 3.2 GA - to do

  • As per the to do list I see progress on including hammer-cli-foreman-host-reports work and so change should get in before the GA.
  • Need to know status about modular repositories from @ekohl; if pending change has been merged or not?
  • Few cherry picks requested and pull request looks sane 3.2 CPs from 09-03-2022 by ezr-ondrej · Pull Request #9143 · theforeman/foreman · GitHub
  • As per the schedule the GA should happen on 15th, do we need few more days to stay in RC? considering RC1 and RC2 were delayed by few days.

• 3.0.2 - to do

  • Still waiting on thor pull request,
    don't install thor, fetching it is sufficient by pcreech · Pull Request #7662 · theforeman/foreman-packaging · GitHub

Katello

• 4.4
  • 4.4.0.RC2 is released
  • 4.4.0 GA release process is posted

Agenda items that have arisen as proposals to changes in the process:

@ehelms:

• Switch Katello repositories to be numbered based on the Foreman version
• Gating nightly publishing of Foreman and Katello only if both Foreman and Katello pipelines are green
• Removing anything “special” in Katello release process to map to Foreman
• Single branching procedure for all projects
• Single release owner
• Single release process

@upadhyeammit:

• 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.

[ekohl]

Apologies for the late notes.

Present: @upadhyeammit (chair), @ekohl (notes), @pcreech, @Zhunting, @iballou

Foreman 3.2

• Feature #34505: Add hammer-cli-foreman-host-reports to the installer - Installer - Foreman is blocked on Debian packaging
• Feature #34126: Deliver EL8 repositories as modular repositories to fix dependency resolution, get automatic dependent module enablement and handle dependency resolution without module_hotfixes - Packaging - Foreman at risk, @ekohl will update the issue with the current status
• Cherry picks: look ok
• Decided to go ahead with the GA on the 15th
• Debian plugin pipeline is failing, should be looked into

Foreman 3.0

• Just merged fix thor bundling also for bionic and focal by evgeni · Pull Request #7677 · theforeman/foreman-packaging · GitHub, pipelines will be kicked

Katello 4.4

• Upgrade pipeline failed for an unrelated reason, should proceed

Other

Switch Katello repositories to be numbered based on the Foreman version

Currently the Katello repositories use Katello versioning (see Index of /katello). This means users need to map some Katello version to some Foreman version. It also means that in Foreman’s branching process the packaging we can’t simply replace nightly with 3.3, but need to look for each one if it needs to be 3.3 (Foreman) or 4.5 (Katello). Th
e proposal is to get everything aligned on a single standard.

One suggestion is to bump both Foreman and Katello to a common number (5.0), but there’s no concensus and no decision.

Gating nightly publishing of Foreman and Katello only if both Foreman and Katello pipelines are green

There is an open RFC for this:

Proposal: Merging foreman pipelines with pipelines of other plugins

The current release pipelines are problematic for a few reasons: Katello Nightly is about the least stable of all environments as foreman releases (or other plugins) can get pushed to nightly which can break katello Foreman ships the katello installer bits as part of its repos, so these get shipped out separately (and ahead of) katello. I’d like to propose that we combine the foreman and katello pipelines into one. This would bring in other plugins such as REX into the main release pipeline.…

Other agenda items postponed to a later meeting