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 tag.sh 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?
- Align the redmine issue management as similar to Foreman. Specially the way Foreman uses
-
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.