Katello 4.1 Branching Process

Development Releases
1

Katello 4.1

We are approximately 1 month out from branching Katello for the 4.1 iteration. As usual, we aim to keep pace with the Foreman development cadence.

Branch Target Date: May 4 2021
Stabilization Week: April 26-April 30 2021
RC1 Target Date: May 6 2021

One Month Prior to Branch Date (April 4, 2021)

Release Owner (@jeremylenz )

  • Announce upcoming branching to discourse development category a month before
  • Start extracting i18n strings and pushing the changes into master git branches so Transifex can pick it up
  • Update Katello Transifex translations:
    • Create a Transifex account and join the Foreman team
    • Spin up a Foreman and Katello installation
    • Install Transifex client pip3 install transifex-client --user
    • Configure the Transifex client
    • Install grunt
    • grunt i18n:extract in the katello/engines/bastion_katello directory
    • make -C locale tx-update in the katello directory
    • grunt i18n:compile in the katello/engines/bastion_katello directory
    • bundle exec rake plugin:gettext[katello] in the foreman directory
    • Commit the resulting files in the katello directory with a message like “i18n - pulling from tx”

Two Weeks Prior to Branch Date (April 20 2021)

Release Owner

  • Add tool_belt config for new release tool_belt configs
    • Check the nightly config file if any repos/tags need to be updated in the newly created config.
  • Ensure stable Pulp release

Release Packager

  • Ensure tool_belt config is merged and output from ./tools.rb koji configs/katello/4.1.yaml matches expectations
  • Ensure releases of installer modules, this is typically done as part of Foreman module release workflow

On Branch Date (May 4, 2021)

Release Owner

  • Create KATELLO-4.1 branches

  • Bump versions to 4.2-master

  • Create PR to foreman-infra to add a mapping between the current Foreman and Katello release branches. Also remove the oldest mapping from the config. See this example.

  • Branch docs

    • Use ./tools branch-docs config/katello/4.1.yaml to branch automatically or by hand:
    • Draft release notes in markdown (example), with these sections (and do not use personal pronouns):
      • Headline features: half a dozen important features with a few sentences description each
      • Upgrade notes: all important notices that users must be aware of before upgrading
      • Release notes: bullet point list by category of most changes, excluding bug fixes for issues introduced during the release cycle, include link to bug numbers. You can auto-generate changes using the ‘changelog’ command in tool_belt
      • Add contributor list on release notes page ex git shortlog -s KATELLO-3.17..KATELLO-3.18

  • Update API docs and open a PR with the changes:

    VERSION=
GITDIR=~/git  #directory containing theforeman.org git repo

FOREMAN_APIPIE_LANGS=en rake apipie:cache
cp -rf public/apipie-cache/* $GITDIR/theforeman.org/plugins/katello/$VERSION/api
find $GITDIR/theforeman.org/plugins/katello/$VERSION/api -name "*.json" -type f -delete
sed -i "/layout: /d" $GITDIR/theforeman.org/plugins/katello/$VERSION/api/index.md

Release Packager

  • Run ./tools koji configs/katello/4.1.yaml from tool_belt to create Koji tags
  • Run ./tools mash-scripts configs/katello/4.1.yaml from tool_belt to create Koji mash configs and open PR to tool_belt to commit
  • Copy mash configs to Koji (/etc/mash)
  • Update the branch map in the mash script and deploy it to Koji
  • Add 4.1 to Forklift versions config
  • Add new Katello release job to foreman-infra
  • Update Katello PR pipeline with new version pipeline
2 Likes
2

This should probably move to a week or two before branching, to avoid cases we’ve had in the past where only at branching (or later) we realized some of the installer changes weren’t done yet

2 Likes
3

This PR was opened to fix that:
https://github.com/theforeman/tool_belt/pull/347

1 Like
4

I like to add more details about pulling the translations and extraction of new strings,

  1. We at least extract and pull new strings for Foreman before branching, before every RC and prior to GA.
    • This ensures whatever changes we cherrypick prior to GA are extracted for translations.
    • The new strings are translated and merged, RC1 strings are translated by RC2 and likewise RC2 strings are translated by GA.
  2. We dont extract strings from develop until x.y.z release is GA.
    • This means from branching to GA we pull and push translations from latest stable branch only. Now its 2.5 for Foreman and 4.1 for Katello.
    • This is to make sure we dont have any conflicts between develop and stable strings. We need to follow this as on Transifex strings are not managed release wise.

Considering this I request to diligently push and pull the strings so we have better percentage of translations overall for Katello.

5

@upadhyeammit thanks for the feedback! To clarify my understanding…

Current state: A couple weeks ago I pulled translations from master. Then we branched. So I will pull the next translations from the KATELLO-4.1 branch. Does that sound correct?

Actually, it would be helpful if you could review this PR and suggest what changes should be made to the above checklist: