Chaotic notes below (but hey, we are aligned!). Someone correct me if I misunderstood $stuff. Or add missing stuff.
2018-07-09, 17:00 Present: Javier, Michael, Tristan, Andre. Matthias was busy but aware. Tobias joined for a while. * MC: Invite another specific individual to the team who is already doing stuff that r-t is doing? ** Javier, Andre, Michael, Tristan: +1 ** ACTION: Javier to contact and to update https://wiki.gnome.org/ReleasePlanning/Membership afterwards * Buildstream ** We switched to it, now to make it better that developers can use it ** Tvb: Would love to have tarballs (now we have git master) in CI / gnome-build-meta regularly, like once a day or such ** JJ: Can be done but now we mimick what we had before (jhbuild, gnome-continuous?) ** MC: Latest tarballs: Maintainers do not release at the same time, can become a problem at release day ** JJ: Have two pipelines instead of one, try to do a release 'all the time' ** JJ: Automate as much as possible ** MC: Mail notifications about side branches are a bit noisy ** MC: Still to be discussed: Tarballs need to be downloaded from the same GNOME server ** MC: Only external stuff creating problems sometimes when servers are down (Sourceforge, RedHat, etc) ** Jvb: Source mirroring in general complicated; interoperability needed because you want to trust that upstream has not rewritten history, prefer potential existing solutions. ** MC: For GNOME, ideally we build the latest tarballs and dependencies, but also limits ** JJ: Try to use more git via tags and less tarballs? ** Tvb: In general +1; for third party modules to increase reliablility ** MC: GNOME dependencies might have to support two versions then, tarballs and latest git master? ** JJ: Yes, and that is welcome ** MC: We can also track latest stable from git not unstable git master; Tvb and JJ +1. ** JJ: To avoid tarballs that are years old ** MC: Need to find out what is the latest *stable* git tag ** Tvb: Probably not possible yet because cover corner cases like capslock pre-merge experiment etc. ** JJ: Tags are not just releases. ** JJ: Priority#1 gnome-build-meta to build / generate a flatpak at runtime ** JJ: want to deprecate gnome-sdk to generate the flatpak gnome runtimes ** JJ/Tvb: Priority#2 Clarify situation of gnome-apps-nightly, want individual apps to manage their on build. ** Tvb: "Fix the story of building flatpaks." ** MC: Priority#3 potentially deprecate gnome-apps-nightly ** MC: Priority#4 then deprecate gnome-continuous ** Tvb: freedesktop-sdk and gnome-build-meta to act together to create an image via buildstream to boot. hopefully directly from filesystem without creating an image via qemu ** MC: flathub is for stable only ** JJ: flatpak builder or buildstream? ** Should core apps behind the same way? They have a CI to push to gnome-repo ** MC: Want some r-t quality control on the process? ** Tvb: Why do we run core apps in flatpak (productivity tools like epiphany, nautilus)? Where to draw the line? ** JJ: Priority#2 r-t to manage gnome-build-meta, and then we push from that CI job to gnome flatpak repository for limited number of our core apps *** MC: core apps is our recommendation what distros should ship by default ** MC: would like to see debug/development and release builds (via conditionals?). Should apply to runtime as well. Using address sanitizer (like valgrind without valgrind) in gcc ** Tvb: but crashes until every issue is fixed due to address sanitizer crashing? ** MC: application developers to add hardening CFLAGS? Or automatically? (change defaults for flatpak builder?) ** Tvb: First try in gnome-build-meta, later try add same option in freedesktop-sdk and see if it works or not ** TM: When you build apps via flatpak manifest, usually build for your own, different from producing binaries for 3rd party, and production binaries for people to actually use. Not clear how do we support these separate usecases? Separate manifests? ** Tvb: Flathub should allow users to test new software throw flatpak, then to get rid of gnome-apps? ** MC: Problem: Flathub needs manually updating currently. Step should not exist ** JJ: We have CI in Gitlab for that * Access control to security tickets in Gitlab ** Tvb: Consider creating subgroups, issue project spaces not related to an actual repository which can have separate permissions and membership ** JJ: Check if in CE or only in EE ** Tvb: If not we can create a dummy repo ** JJ: Are there issues / tickets for all these things? Track progress! -- Andre Klapper | [email protected] https://blogs.gnome.org/aklapper/ _______________________________________________ [email protected] https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
