On Tue, Sep 27, 2022 at 09:33:27AM +0100, Daniel P. Berrangé wrote: > On Tue, Sep 27, 2022 at 01:43:15PM +0530, Ani Sinha wrote: > > On Sun, Sep 18, 2022 at 1:58 AM Michael S. Tsirkin <m...@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 <a...@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 > > > > > > > > <m...@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? > > If QEMU is hosting binaries, where any part contains GPL code, then we > need to be providing the full and corresponding source and the build > scripts needed to re-create the binary. Once we have such scripts it > should be trivial to trigger that from a CI job. If it isn't then > we're doing something wrong. The CI quota is not an issue, because > this is not a job that we need to run continuously. It can be triggered > manually as & when we decide we need to refresh the binary, so would > be a small one-off CI quota hit. > > Also note that gitlab is intending to start enforcing storage quota > on projects in the not too distant future. This makes it unappealing > to store binaries in git repos, unless we genuinely need the ability > to access historical versions of the binary. I don't believe we need > that for biosbits. > > The binary can be published as a CI artifact and accessed directly > from the latest artifact download link. This ensures we only consume > quota for the most recently published binary artifact. So I don't see > a compelling reason to upload binaries into git. > > With regards, > Daniel
I don't really care where we upload them but only having the latest version is just going to break anything expecting the old binary. > -- > |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o- https://fstop138.berrange.com :| > |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|