Why we should avoid new submodules if possible

[Thomas Huth <thuth@redhat.com>]

On 28/06/2022 12.03, Michael S. Tsirkin wrote:
[...]
> For biosbits if we are going this route then I feel a submodule is much
> better.  It records which version exactly each qemu version wants.

As far as I know, you can also specify the version when using pip, can't 
you? So that's not really an advantage here.

On the contrary, submodules have a couple of disadvantages that I really 
dislike:

- submodules do not get updated automatically when doing a "git checkout", 
we have to update them via a script instead. This causes e.g. trouble if you 
rsync your source tree to a machine that has no access to the internet and 
you forgot to update the submodule before the sync

- the content of submodules is not added to the tarballs that get created on 
the git forges automatically. There were lots of requests from users in the 
past that tried to download a tarball from github and then wondered why they 
couldn't compile QEMU.

- 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?

- If programs includes code via submodules, this gets a higher
   burder for distro maintainers, since they have to patch each
   and every package when there is a bug, instead of being able to
   fix it in one central place.

So in my opinion we should avoid new submodules if there is an alternative.

  Thomas