request to periodically make versioned tagged releases

[hgkamath]

• Firstly, Thanks to gfxstream+magma+rutabaga team / Google for the opensource contribution
• Just a user here.
• The Linux distribution version of gfxstream seems to not have been updated in a long time.
• The Fedora koji build [3] still seems to be using version 23d05703 [4] which dates back to 20231003 , which ATTOW is over 2 years old.
• The hesitation might be that when manually looking at the commit logs as an outsider, one cannot know if any given commit version is stable enough to build with, and/or (very likely) that downstream builder scripts need an detectable upstream tag to automate building.
• There seem to be bugs like mesa-15796 [5] which suspect version mismatch or outdated code. The existence of that issue is also evidence that there are Linux users / developers willing to try gfxstream out and try make it work.
• Filing this issue to suggest to gfxstream team to make periodic versioned tagged releases so that downstream distributions catch up.
• To users, the benefit of gfxstream on more platforms is that
  • allow for use cases of gpu acceleration where virtio-gpu is not available or does not work.
• To gfxstream project, the benefit of periodic versioned releases is that
  • there will be more users of gfxstream testing out the code paths via gfxstream.
  • more security, plumbing and bit-copy bugs will get reported and fixed. hence making gfxstream more reliable for android also.
  • bugs will be reported on specific versions with known feature maturity
• It is understandable that gfxstream may not want the maintainance burden of supporting Linux to high reliability, as it focuses on android. It is sufficient to
  • (1) make a just-able-to-initialize-and-use sanity version every now and then and let the Linux volunteers report or iron out the Linux bugs.
  • (2) make sure android-studio, mesa and qemu will build with that version
• Perhaps one can make
  • lockstep version tagging that match with android-studio releases (ATTOW 2026.1.3.7)
    • perhaps use the same commit version that is used by the final released android-studio
  • or lockstep version tagging or that match with mesa (ATTOW 26.2) or qemu (ATTOW 11.1)
  • or independent periodic version tagging yy.mm like mesa or N.#n like qemu
• As to the timing of the version tagged release, candidate times may be
  • at the same time as android-studio
  • or 2 months lead time (Jan Jul) before a Fedora-Workstation release (Apr Oct). Fedora usually picks up bleeding edge versions of packages The lead time is usually enough time to sort out build errors, before the publication of the Fedora Linux distro (6 monthly).
• The version tag gives some idea of how old the code that is used to build the binary file of the gfxstream library, is.

Ref:

• [1] Google Upstream gfxstream repository
  https://android.googlesource.com/platform/hardware/google/gfxstream
• [2] Fedora downstream repository
  https://src.fedoraproject.org/rpms/gfxstream.git
• [3] Fedora koji build by @elmarco
  https://koji.fedoraproject.org/koji/packageinfo?packageID=39771
• [4] gfxstream git commit 23d05703
• [5] gitlab mesa "gfxstream: How to identify the matching host gfxstream_backend version for Mesa's libvulkan_gfxstream.so?"
  https://gitlab.freedesktop.org/mesa/mesa/-/work_items/15796

[gurchetansingh]

Ack: we should be doing this. I'll assign to myself and hopefully we'll have a new release sometime by Q4.