Freedesktop-sdk BoF 27/08/2019

Etherpad link: https://etherpad.gnome.org/p/freedesktop-sdk-bof

Agenda

• Collaboration with downstream projects:
  • GNOME, KDE, elementary, librem ...
  • Does freedesktop-sdk provides everything thet need? (drivers, hardware support ... etc)
  • Can we move common components to freedesktop-sdk?
    • seems librem are happy with the current release
      • They intend to ship a flatpak extension for some requirements
      • No plans to release this though until after the next release
    • Elementary are baing their rutime off the gnome-runtime, which is based off of the freedesktop-sdk
• Release Cadence

  • \url{https://gitlab.com/freedesktop-sdk/freedesktop-sdk/wikis/release}

  • No changes seems to be needed
• Consider stable backwards compat policy on master in between stable snapshots ?
  • ABI not the full story, e.g. config files
    • improve checker?
    • gobject tracking etc
  • Problem mainly occurs for usb installs from endless etc
  • track hash of sdk at build time, require that hash in the history to run?
    • this way we ensure symbols used always in runtime
  • Allow multiple of same runtime?
    • Allow apps to demand a certain minor release point (or newer)
    • may end up with a lot of refs - summary file scalability
    • Version by XX.YY.Z.W, bump W unless we add symbols, then bump Z
    • Do we also do this for the SDK?
    • Make everyone target the first released SDK
    • The solution also has to consider extensions
• How long do we support stable releases ?
  • No changes needed
• API surface, which parts of the SDK are considered stable API for dependent downstream projects, how do we define this clearly ?
• Snap support
  • Missing bits will be solved in a couple of months
  • Happy to publish in canonical store
  • Need VM and or OCI images from fdsdk
  • Some suggestion about building the Firefox snap with this
  • How Mesa extension would work on the snap and nvidia drivers
  • codecs status
    • Due to distros shipping older versions of Flatpak the html5 codecs extensions still needs to be used
    • need to check if it kills the transaction completely, mark non-autodownload if not
    • should change the extensions to have same use-style anyway
• CI improvements
  • only test at the moment is build and run hello world(s)
  • want to run beta builds on flathub(?)
  • openqa tests for apps
  • extract tests to separate place?
• Power support on flathub
  • Needs support in flathub for optional CI builds
  • Needs trusted machine before publish
  • maybe also blocked on repo hardware at flathub
  • new repos for new architectures?
• armv7 support beyond 2021
  • Discussion if armv7 is needed after 2021 (ie, if it can be remove from the 20.08 runtime release)
  • Main concerns are maintenance costs by the number of users and hardware support to existing devices using flatpak (like endless ones)
  • Flatpak maintainers and Endless representatives agreed support until 2021 in the 19.08 fdsdk runtime should be enough

Actions

• Discuss in mailing list about backward/forward compat solutions
• coldtom: check if transaction dies, make sure noopenh264 is added before release
• publish a docker image containing flatpak and snap to allow building both in docker
• Get power64le runners for Flathub
• Javier: disable armv7 builds for new master
• Javier: contact oregon university to improve bandwidth on x86\_64 runner
• Javier: contact freedesktop.org, about centralising the donated runners for freedesktop-sdk/Flathub/GNOME, to one big central runner cluster (kubernetees?)
• Add policy of open issue when we add downstream patches