Re: Why we should avoid new submodules if possible

[Peter Maydell]

On Tue, 28 Jun 2022 at 11:38, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Tue, Jun 28, 2022 at 12:21:39PM +0200, Thomas Huth wrote:
> > - we include the submodule content in our release tarballs, so people get
> > the impression that hte submodule content is part of the QEMU sources. This
> > has two disadvantages:
> >  * We already got bug reports for the code in the submodule,
> >    where people did not understand that they should report that
> >    rather to the original project instead (i.e. you ship it - you
> >    own it)
> >  * People get the impression that QEMU is a huge monster
> >    application if they count the number of code lines, run
> >    their code scanner tools on the tarball contents, etc.
> >    Remember "nemu", for example, where one of the main complaints
> >    was that QEMU has too many lines of code?
>
> I think we can skip the checkout in the tarball if we like.
> If people want to run the test they can checkout then.

For tarballs and submodules, we want to provide the code in the
cases where we're providing binary blobs, and for where it's
required to build QEMU proper.

Overall I think that the approach we use today for providing
guest binaries (submodules with the code, pre-built blobs checked
into git) is creaking at the seams and often awkward for downstream
distros (who want to rebuild the binaries anyway).

Plus submodules in general in git work really badly and awkwardly,
and I'd rather we didn't add them unless we really must.

We already have an approach for "tests that use binaries" --
the avocado test suites. Is that something we could use in this
case ?

thanks
-- PMM