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-repositories-from-kubernetes-code

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