Re: Why we should avoid new submodules if possible

["Michael S. Tsirkin" <mst@redhat.com>]

On Tue, Jun 28, 2022 at 11:43:58AM +0100, Peter Maydell wrote:
> 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

From experience avocado is basically rolling its own reimplementation of
git fetch. Result is weird failures when some corner case or another
isn't handled perfectly. Kind of unavoidable since you can't have
ISOs for a ton of guest OSes reasonably in a git repo. Well maybe
with sparse checkouts you can. Haven't really looked at it.

These specific tests are weird, kind of special in that they are developer
oriented.  I *would* like anyone making changes to ACPI to run them, and
for CI to run them on patches, but I do not believe e.g. distros
necessarily need them.

git submodules are awkward basically because they are an automated wget.
I don't think an explicit wget is much better ... but
looks like I'm alone in this. Oh well.
So it will be a weird dance of wget a tarball, unpack, generate
ISO and run. God help you if you need to patch the test - it's
wget all the way down.


-- 
MST