Hi all Moving the source into kata-containers repo and keeping the original golang package as a copy may be a good idea. Like the Kubernetes way: https://github.com/kubernetes/kubernetes/tree/master/staging#using-staged-re... It will only need external work to sync the code. 2021年7月28日(水) 16:28 Christophe de Dinechin <cdupontd@redhat.com>:
On 28 Jul 2021, at 09:50, Fabiano Fidêncio <fabiano@fidencio.org> wrote:
Folks,
David Gibson, in an internal conversation, raised Today the pain of trying to fix a QEMU + kata-containers issue, having to update govmm, get it reviewed & merged on the govmm side, and only then be able to proceed with the work on QEMU + kata-containers. I can relate to that, I'm pretty sure other developers can relate to that as well.
Considering that govmm is only used by kata-containers, wouldn't it be the case to have it as part of the virt-containers package rather than it's own project that we vendor? I tend to see this as taking a step towards how we integrate cloud-hypervisor with kata-containers.
What do people think about this? Is this a move we can make as part of the 2.3 release cycle? Or are there other users of govmm that we missed?
Even if that's the case, we can still keep some external repository in sync with the internal code, e.g. using git subtrees and exporting govmm "releases" for external consumers.
Opinions, concerns, suggestions, all of those are super welcome.
Best Regards, -- Fabiano Fidêncio
_______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
_______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev