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

GUADEC/2019/Hackingdays/GNOMEOS/Notes (last edited 2019-09-01 22:13:26 by JordanPetridis)