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

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

On Sat, Jul 16, 2022 at 12:06:00PM +0530, Ani Sinha wrote:
> 
> 
> 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.

Well we need some schema. Given we are not using official bits releases
I don't think we can reuse theirs.

> 
> 
> 
> 
>     > (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.
> 
> 
> 
> 
>