[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Why we should avoid new submodules if possible
From: |
Michael S. Tsirkin |
Subject: |
Re: Why we should avoid new submodules if possible |
Date: |
Wed, 28 Sep 2022 05:47:51 -0400 |
On Wed, Sep 28, 2022 at 11:33:52AM +0200, Thomas Huth wrote:
> On 28/09/2022 11.26, Michael S. Tsirkin wrote:
> > On Tue, Jun 28, 2022 at 12:21:39PM +0200, Thomas Huth wrote:
> > > 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
> >
> > So looking at the latest proposals downloading files from CI,
> > checksumming them etc etc. No auto checkout, not added automatically
> > either, right?
> >
> > This seems to be the only difference:
> > - we include the submodule content in our release tarballs
> >
> > How about we just fix that? Thomas would that address your
> > concern at least wrt tests?
>
> If I'm not forced to checkout that submodule,
I think the make check script can do that?
> and if we don't add it to the
> release tarball, I guess there's not much left I can complain about ;-)
>
> Thomas