GUADEC 2018 r-t meeting notes

[Andre Klapper <ak-47 gmx net>]

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  |  ak-47 gmx net
https://blogs.gnome.org/aklapper/