What happened since last call

• Requests repository was renamed
• Bunch of new stuff got built
• We have a mailing list for the review/maintenance team, not sure if it's really working though
• Allan chatted with Neil about legal framework stuff, this is blocking a more wide announcement

Mailing list may not be properly working

• Something needs a root password account on fd.o
• ACTION: Rob will unblock this by looking for his root pwd on a magic piece of paper

Legal framework

• Neil should chat with Rob, there's a lot that needs figuring out there
• We should individually be protected from liability
  • Also our employers should be protected from liability
• If we could get time from the legal advisors the GNOME Foundation has, this could be useful
  • But we should not necessarily try to centralize the liability into a single organization and "staple all together"
• For instance, in ChromeOS, "the Chromium authors" are responsible for the bits; there's Google in the mix, but it's not all them
• If something were ever to happen, legal backing should be nice to have though
  • Could be as easy as a resolution from the GNOME Board committing to use our legal resources should things get bad
• Another aspect of this is how the legal framework affects partners that want to enable this out of the box
  • There may need to be an organization that they can relate to
  • This is a good place to be though, we first need to figure out the basics
  • We're not trying to centralize a stronger guarantee of liability than the rest of the operating system, for people that want to enable this by default

Sysadmin time

• We need to have a solid repository server
  • If the build backend goes down for a couple days, it's not the end of the world, but the frontend should stay up
• The GNOME Foundation could also possibly help with funding this
• ACTION: Alex will write down the current architecture of the system and its requirements, to share it with the sysadmin team

Outreach

• Allan reached out to KDE e.V., TDF, Mozilla and other players in the space
• We're trying to organize a call with them at a higher-level to get things started

Website

• Do we want to make something nicer before we go wider announcing this?
  • Jakub has something in the plans, but it's not done yet
• The buildbot UI could also be tweaked a bit, by e.g. adding a Flathub logo somewhere
  • Tom was interested in this?
  • The buildbot config is in github so this should be easy

Try builds/PR workflow

• This is very manual -- someone needs to manually press a button to build a request
• Buildbot may have a way to build stuff based on a PR comment, but we have not looked into it
• ACTION: Bartlomiej to look into it this week

Using Flathub for GNOME stable builds

• Carlos pushed Nautilus, but before we do it for all the other applications, we'd need redirection between repositories to update
  • ACTION: Alex is working on this today already
  • Once that's out of the way, Carlos will continue
• We'll live with duplicate manifests for the time being -- one in git and one stable in flathub that uses tarballs

Stats for downloads

• We'd like to have automated log collections to make download stats
• This is part of the value that Flathub can create for upstream projects
• Not hard, we need some sort of back mapping to app IDs from the commit SHAs or deltas, but needs to be done
  • This is kind of in between a sysadmin and a developer task
• If we had the stats, how would we make them available?
  • This opens up larger questions, could be on-demand for now

Themes

• Matthias talked to Richard for gnome-software integration, but did not come to any conclusions yet
  • Could be manual for now, but longer-term we should have something automatic
• The minimum issue here is that since the runtime only contains Adwaita, all the apps use that instead of the distro theme
• There's also a technical issue; GTK2 and QT themes are .so files so they have a hard dependency to be built for a specific platform
• Would be useful to have examples even just for icon and GTK3 themes though, so that more people can start adding new themes
  • The extension point right now is versioned with the GTK version
• For QT, we should begin by having the KDE runtime on Flathub

Support/updates

• We should at least set expectations for things like security issues
• We should also have a framework where we can make errata-like processes (e.g. updates are announced on a certain day) possible
  • E.g. skip the queue for security builds

GPG key

• The key is in a locked/encrypted file in another machine
  • Hard to do better than this without a HW crypto machine
• Alex has master password

"extra-data" kind of applications

• There would be a benefit to put them in flathub
• Should have a watchdog at least when the links are 404
  • Endless has this
• Do we want them there?
  • Seems that we'd want them, but we need to at least separate them out because not everyone may want to see them since they're not free software
  • What is the official plan?
    • Tagging them as free/non-free, then have a toggle in gnome-software
    • Right now, the appdata.xml contains the license tag, and if there's a proprietary license, has support to show it/with an EULA (but there's no support for the EULA in the appdata ATM)
    • There's some license-tracking in Yocto, could be valuable to converge there
  • There's a benefit launching 1.0 with these apps in, to set the right expectations

Screenshots hosting

• We don't do this, but since we have a webserver, we could do that here too
• There's an appstream util to rewrite screenshots, used in Fedora
• ACTION: Alex to look into this with Richard

Source code archiving

• There's a flatpak extension that makes this possible
• We can enable this by default in Flathub
• ACTION: Alex to do that

Build logs

• We don't index by app, so it's a bit hard to find logs right now
• Not high-prio, could probably be done with buildbot
• Needs someone to look into this