What is our docs backport strategy?

Last week I found it very difficult to use the backport bot and get backports for a lot of the hacktoberfest PRs. These PRs tend to hit a number of files and there are various conflicts even going just to stable-2.16 for these fixes.

So - how far back do we want to go in cleaning this up?

As a bit of background, until recently, I just did manual backports to one stable branch prior to devel (aka 2.16 in this example). Then smart folks added a backport bot to the new docs repo and things were grand for a time. We could automate backports all the way down to stable-2.13 (last active release). Unfortunately, we weren’t consistent on applying the labels to enable these backports and things got out of sync.

So now the question is - other than stable-2.16 (what will be latest soon), how far back do we go in untangling this mini mess we got ourselves into?

My recommendation is that we stop stable-2.13 for sure as that goes EOL soon.

Do we bring stable-2.15 and stable-2.14 back into alignment as well to enable backports again?


In the DaWGs meeting we decided to keep the highest stable version in sync (aka 2.16). All else is ‘best effort’ which means trigger the backport bot, but if it fails, then we don’t try a manual bckport workaround etc.

@felixfontein @gotmax23 would like your thoughts on ^^ , especially with regard to steering committee controlled docs.

Most (all?) SC docs are only available on the package docsite, so we should only need to apply them to stable-2.16 and stable-2.15 until ansible 8 is EOL.


That’s basically what I also do with backports in community.general, except that if the backport fails to the latest stable branch, I usually try it manually to figure out what went wrong (except for changes that definitely souldn’t be backported at all).

So :+1: from my side!