Cleanup of foreman-documentation branches

Hello,

I’ve implemented upstream branching too late, beginning this year actually, and Red Hat documentation team needed some branches to work with for 6.7, 6.8 and 6.9 releases, therefore we ended up in a messy situation I would like to propose to fix branches in the foreman-documentation repository.

The following branches are correct and stays untouched:

  • master
  • gh-pages

The following is the only stable branch we currently have, we are about to branch off 2.4 release:

  • 2.3

Now, since we have upstream branches and every Satellite release has a counterpart version upstream, for 6.9 it’s 2.3, I propose we delete all Satellite related branches from github and only keep upstream version branches.

  • SATELLITE-6.7
  • SATELLITE-6.8-beta
  • SATELLITE-6.8
  • SATELLITE-6.9-beta
  • 6.7
  • 6.8-beta

There is a script in RH docs git repo (gitlab) which must be updated to pull changes from the correct branches, but that should be the only change we need to do. I will compare all commits in 2.3 and SATELLITE-6.9-beta so there are no unwanted changes after we do the switch.

I also propose to improve our PR review process. Going forward, should be applying more strict rules for merging PRs into master. My proposal is to follow the same workflow we have for Foreman repositories:

  • all fixes go into master first
  • every PR a single commit (we need a GH action for that)
  • every PR that must be cherry picked must be marked in the description (I will do cherry picks myself - let’s create a PR template for that the same way as in foreman-packaging)
  • every PR must be reviewed and approved
  • merging own branches is not allowed

In Foreman core we have a regular meeting every week to go over all commits in develop branch and consider cherry picking them. I propose to do the same for documentation, either on the same meeting or another one. I currently have a meeting conflicts with that. But this would allow to land many good improvements in stable branch. What do you think? Who would like to attend those meetings (30 min slot probably just 5 minutes each).

Thanks, cheers.

In the platform team we have some exceptions to this. Often something needs to be done in lockstep. For example, a change in puppet-foreman should only be merged after a change in foreman is merged (similar examples exist in foreman_proxy and katello). We often approve it pending merge of the related PR. The author is then allowed to merge their own PR once the dependency is resolved. Documentation feels like a similar thing where you have these kind of dependencies.

1 Like