Notes are at https://etherpad.gnome.org/p/GNOME-OS_BoF

GNOME OS BoF Notes

Agenda:

• VM images - gnome continuous deprecation? (ostree)
  • old vm images from continuous are built from an old Yocto base
  • moved to gnome-build-meta built on top of freedesktop-sdk
    • vm images are now generated there

    • but the artifacts are too big for gitlab (> 5GB)'

  • Could we upload the images to the same place as gnome continuous?
  • Could we use ostree update as a way to have a minimal image that downloads the full image from ostree.
    • The current implementation for the ostree update uses an initramfs, we could maybe use just this as minimal image
  • continuous mode
  • ostree repo?
  • openQA
    • OpenQA app launching and extended test
      • It's pixel based, is it good enough? Font updates will break everything!
      • Think about common setup with other OpenQA users like Endless OS? Common set of tests upstream?
      • Reuse OEM tests (Graphical)
    • Fedora has been using it for a while, testing Fedora Workstation (GNOME) ; we can probably ask Adam Williamson (adamw) for help, and maybe even share the work on the reference screenshots
    • Phihlip has some eperience too
    • Should publish openQA tests as gnome specifications
  • Another possible artifact type besides VM images is Amazon EC2 AMI (or maybe some other type of cloud image), accessible over noVNC in a web browser
  • VM images are not only for CI to test things on, but also to serve as a showcase of GMOME technologies and provide examples "how GNOME experience should be" to traditional distributions
• CI - docker images for module mantainers?
  • Proposal for workflow to test modules:
    • Module CI would rebuild gnome build meta image with the modified module
    • This might have issues scaling
  • Let's try to do it with one module to see if it works
  • gnome-build-meta CI trigger CI of all apps
    • No core apps on g-b-m
    • We avoid duplication of metadata
    • CI of core modules (gnome-shell) should be g-b-m (maybe allow to fail)
    • metadata in g-b-m so that it is possible to notify owner
• Dependency policy
• Release schedule changes - runtime maintenance
  • GNOME has more responsabilty because we now ship a flatpak runtime
    • This needs to be maintained for at least a year
    • In a stable cycle we could release an unstable cycle of the runtime
    • consider having a vulnerabilty point of contact in GNOME
      • allows for a direct point of contact to lear about new CVEs
    • consider having a point of contact for a specific release point
      • this person changes per release point
    • maintainance time should not end right at the same time as a release but should have ~2 months after. For instance, a year of maintainance should mean ~14 months.
    • applications should have kudos in GNOME software for using newer/non-vulnerable runtime to pressure developers to update

      • \url{https://gitlab.gnome.org/GNOME/gnome-software/issues/780}

• Tarballs deprecation
• Commit refs into the build-meta repo
• gnome-build-meta (library) test suites
• should apps even be in gnome-build-meta? (need to maintain metadata there in addition to flatpak, and even core apps would be distributed as flatpak anyway, not from g-b-m)t
  • we dicussed what would be classed as a core app
  • build flatpaks from g-b-m using upstream flatpak manifest
    • no duplication
    • needs flatpak manifest plugins - source and build several components at once
• Remove an app from GNOME OS If an app is available and up to date on flathub and has a working CI that uses flatpak?
• runners situation

Actions

• Checkout element refs in the gnome-build-meta repo and implement an auto-update like functionality that tracks and opens MRs.
• Finish VM generation
• Implemtnt ostree repo generation
• Talk with openQA people about what is needed to setup
• Prototype CI using g-b-m and buildstream
• Prototype the gnome-build-meta Docker images inside epiphany CI or glib-networking
• Start investigating 'Developer Mode' and Build tools with the Design team
• Javier: review apps in core and remove when they meet criteria
  • have ci, flatpak , publish on flathub

• no tarballs -> make signing tags mandatory (at the end the release team would re-sign tags signed by developers), that's because we need to somehow authenticate the sources

• javier: check will Allan about core apps
• Fix everything to use flatpak repos instead of flatpak bundles