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

[Ani Sinha]

On Sun, Sep 18, 2022 at 1:58 AM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Fri, Sep 16, 2022 at 09:30:42PM +0530, Ani Sinha wrote:
> > On Thu, Jul 28, 2022 at 12:08 AM Ani Sinha <ani@anisinha.ca> wrote:
> > >
> > >
> > >
> > > On Mon, 25 Jul 2022, Ani Sinha wrote:
> > >
> > > >
> > > >
> > > > On Sat, 16 Jul 2022, Michael S. Tsirkin wrote:
> > > >
> > > > > 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.
> > > >
> > > > OK fine. Lets figuire out how to push bits somewhere in git.qemu.org and
> > > > the binaries in some other repo first. Everything else hinges on that. 
> > > > We
> > > > can fix the rest of the bits later incrementally.
> > >
> > > DanPB, any thoughts on putting bits on git.qemu.org or where and how to
> > > keep the binaries?
> >
> > Can we please conclude on this?
> > Peter, can you please fork the repo? I have tried many times to reach
> > you on IRC but failed.
>
> Probably because of travel around KVM forum.
>
> I think given our CI is under pressure again due to gitlab free tier
> limits, tying binaries to CI isn't a great idea at this stage.
> Can Ani just upload binaies to qemu.org for now?

I agree with Michael here. Having a full ci/cd job for this is
overkill IMHO. We should create a repo just for the binaries, have a
README there to explain how we generate them and check in new versions
as and when needed (it won't be frequent).
How about biosbits-bin repo?


>
> --
> MST
>