Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

request to periodically make versioned tagged releases

Aperta
  • Qualcosa non va?
#166 1 commento 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

@gurchetansingh ci sta già lavorando.

Dal 3/8/2026.

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

  • 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:

Lingua principale
C++
Stelle
63
Fork
42
Merge medio
17h 53m
PR unite (30g)
6

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di google/gfxstream

Tutte le issue di google/gfxstream

Issue simili

Altre issue su C++

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.