[kata-dev] Kata 2.0, PR porting, and an idea

Hunt, James O james.o.hunt at intel.com
Wed Aug 26 15:54:49 UTC 2020

Hi All,


- See new project [4].
- See "Future plans" below.

# Background

As you probably know, we are developing Kata 2.0 in [1] but continuing to work on 1.x in the other repositories.

When a PR gets raised on a 1.x branch, it often also makes sense to apply that (forward port it) to the 2.0 branch. We've been adding the "port-to-2.0" label as an indicator that this needs to happen.

However, sometimes PRs get raised on the 2.0 branch first, and it makes sense for some of those PRs to be applied to a 1.x repo (backported). We do have a "backport" label but that hasn't been used much it appears.

But there are also 1.x stable branches so 1.x bug-fix PRs may need to be back-ported to stable-${version} (and 2.0 bug fix PRs might need to be backported to both 1.x master and stable-*).

# Challenge

I've spent a bit of time looking at the "common repos" between 1.x and 2.0 [2] and -- unsurprisingly since us humans are fallible -- not all expected PRs have been back-ported or forward-ported. Since it's rather time-consuming working out the delta, I've focussed on PRs that haven't been applied to 2.0 but (potentially) should be (aka forward port PRs). However, we should look at the backporting delta more closely later/real-soon-now...

I'm still working through agent and runtime repos, but I've raised new issues in [3] and created a new GitHub project [4] showing this backlog that needs to be cleared before 2.0 is released. Please take a look at this project as you may find you've got some work to do (I've tried to assign the issues to the original PR owners where possible). I may have been over-zealous and raised issues for PRs that have actually landed in 2.0. If so, please comment and close with a link to the PR so we have traceability.

# Future plans

How do we avoid this sort of "dangling back/forward port" problem happening in the future (aka from tomorrow :)? I think the simplest strategy is a semi-manual one:

- Add two *pairs* of new labels to all our repos:
   - "needs-backport" and "no-backport-needed"
   - "needs-forward-port" and "no-forward-port-needed"

- Add GitHub actions to all repos requiring that *one of each pair* is added to every PR before it can be merged (aka block all PRs being merged until that criteria is met for each!)

This is somewhat simplistic but it will force the maintainers to think carefully about each PR before the PR can be merged. The idea being that they:

- decide on an approach for each PR (does it need porting in either direction?)
- atleast raise an issue for the back/forward port work (referencing the original PR).
- apply the labels to the current PR to allow it to land.

I've written a simple GitHub action [5] that can be turned into a set of PRs if we think this makes sense.

What do we think?



[1] - https://github.com/kata-containers/kata-containers/tree/2.0-dev
[2] - agent (potentially), documentation, osbuilder, packaging, runtime.
[3] - https://github.com/kata-containers/kata-containers
[4] - https://github.com/orgs/kata-containers/projects/24
[5] - https://gist.github.com/jodh-intel/8686dd0ad04c9526cb5ba93283805561

https://katacontainers.io/ | https://github.com/kata-containers
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

More information about the kata-dev mailing list