Re: [PATCH v2 07/11] acpi/tests/bits: add python test that exercizes QEMU bios tables using biosbits

[Ani Sinha <ani@anisinha.ca>]

[-- Attachment #1: Type: text/plain, Size: 2656 bytes --]

On Fri, Jul 15, 2022 at 11:20 Michael S. Tsirkin <mst@redhat.com> wrote:

> On Fri, Jul 15, 2022 at 09:47:27AM +0530, Ani Sinha wrote:
> > > Instead of all this mess, can't we just spawn e.g. "git clone --depth
> 1"?
> > > And if the directory exists I would fetch and checkout.
> >
> > There are two reasons I can think of why I do not like this idea:
> >
> > (a) a git clone of a whole directory would download all versions of the
> > binary whereas we want only a specific version.
>
> You mention shallow clone yourself, and I used --depth 1 above.
>
> > Downloading a single file
> > by shallow cloning or creating a git archive is overkill IMHO when a wget
> > style retrieval works just fine.
>
> However, it does not provide for versioning, tagging etc so you have
> to implement your own schema.


Hmm I’m not sure if we need all that. Bits has its own versioning mechanism
and I think all we need to do is maintain the same versioning logic and
maintain binaries of different  versions. Do we really need the power of
git/version control here? Dunno.


>
>
> > (b) we may later move the binary archives to a ftp server or a google
> > drive. git/version control mechanisms are not the best place to store
> > binary blobs IMHO. In this case also, wget also works.
>
> surely neither ftp nor google drive are reasonable dependencies
> for a free software project. But qemu does maintain an http server
> already so that't a plus.
>
>
>
> I am not insisting on git, but I do not like it that security,
> mirroring, caching, versioning all have to be hand rolled and then
> figured out by users and maintainers. Who frankly have other things to
> do besides learning yet another boutique configuration language.


Yeah we do not want to reinvent the wheel all over again.


>
> And I worry that after a while we come up with a new organization schema
> for the files, old ones are moved around and nothing relying on the URL
> works.  git is kind of good in that it enforces the idea that history is
> immutable.


Ah I see your point here.


>
> If not vanilla git can we find another utility we can reuse?
>
> git lfs? It seems to be supported by both github and gitlab though
> bizarrely github has bandwidth limits on git lfs but apparently not on
> vanilla git. Hosting on qemu.org will require maintaining a server
> there though.
>
>
>
> All that said maybe we should just run with it as it is, just so we get
> *something* in the door, and then worry about getting the storage side
> straight before making this test a requirement for all acpi developers.




>

[-- Attachment #2: Type: text/html, Size: 3898 bytes --]