Kata 2.0, PR porting, and an idea
Hi All, # TL;DR - 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? Cheers, James [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.
I'm still working through agent and runtime repos
I've now finished the runtime repo and have added the new issues for potentially outstanding forward port work to the new project [1]. That leaves the agent repo. I think this is best left as a whole community effort as it's going to require significantly more effort to determine the delta (and the new labels hopefully for new PRs in the future). If anyone has any ideas on this, let us know! Cheers, James [1] - https://github.com/orgs/kata-containers/projects/24 --- 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.
participants (1)
-
Hunt, James O