[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: |
Tue, 28 Jun 2022 06:30:16 -0400 |
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.
But of course if you do you do not get updates ;) You do
however rely on a 3rd party to faithfully provide you
correct code based on the version, and host it forever.
> 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
how is pip better?
> - 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.
how is pip better here?
> - 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.
> - 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.
Come on, this is just a test. We *really* don't care if an ISO
we use to test ACPI is using an exploitable version of grub.
> So in my opinion we should avoid new submodules if there is an alternative.
>
> Thomas
Interesting take generally, but I don't see how the logic applies in this
case. Would appreciate hearing your answers to the above.
--
MST
- Re: venv for python qtest bits? (was: Re: [PATCH 11/12] acpi/tests/bits: add README file for bits qtests), (continued)
- Re: venv for python qtest bits? (was: Re: [PATCH 11/12] acpi/tests/bits: add README file for bits qtests), Michael S. Tsirkin, 2022/06/28
- Re: venv for python qtest bits? (was: Re: [PATCH 11/12] acpi/tests/bits: add README file for bits qtests), Thomas Huth, 2022/06/28
- Re: venv for python qtest bits? (was: Re: [PATCH 11/12] acpi/tests/bits: add README file for bits qtests), Daniel P . Berrangé, 2022/06/28
- Re: venv for python qtest bits? (was: Re: [PATCH 11/12] acpi/tests/bits: add README file for bits qtests), Ani Sinha, 2022/06/28
- Re: venv for python qtest bits? (was: Re: [PATCH 11/12] acpi/tests/bits: add README file for bits qtests), Daniel P . Berrangé, 2022/06/28
- Re: venv for python qtest bits? (was: Re: [PATCH 11/12] acpi/tests/bits: add README file for bits qtests), Thomas Huth, 2022/06/28
- Re: venv for python qtest bits? (was: Re: [PATCH 11/12] acpi/tests/bits: add README file for bits qtests), Ani Sinha, 2022/06/28
- Re: venv for python qtest bits? (was: Re: [PATCH 11/12] acpi/tests/bits: add README file for bits qtests), Ani Sinha, 2022/06/28
- Re: venv for python qtest bits? (was: Re: [PATCH 11/12] acpi/tests/bits: add README file for bits qtests), Michael S. Tsirkin, 2022/06/28
- Why we should avoid new submodules if possible, Thomas Huth, 2022/06/28
- Re: Why we should avoid new submodules if possible,
Michael S. Tsirkin <=
- Re: Why we should avoid new submodules if possible, Peter Maydell, 2022/06/28
- Re: Why we should avoid new submodules if possible, Michael S. Tsirkin, 2022/06/28
- Re: Why we should avoid new submodules if possible, Warner Losh, 2022/06/28
- Re: Why we should avoid new submodules if possible, Thomas Huth, 2022/06/28
- Re: Why we should avoid new submodules if possible, Michael S. Tsirkin, 2022/06/28
- Re: Why we should avoid new submodules if possible, Thomas Huth, 2022/06/28
- Re: Why we should avoid new submodules if possible, Michael S. Tsirkin, 2022/06/28
- Re: Why we should avoid new submodules if possible, Ani Sinha, 2022/06/28
- Re: Why we should avoid new submodules if possible, Daniel P . Berrangé, 2022/06/28
- Re: Why we should avoid new submodules if possible, Michael S. Tsirkin, 2022/06/28