Attendees: - abderrahim - Andre - Ebassi - Felipe (for some time) - jordan - mcatanzaro - jjardon - mclasen - tristan
Agenda: 1. R-T is now committee of the Board - impact? - Felipe is our board liaison - We should take minutes of our meetings -- Tristan: the reason for making us 'official' is to delegate the definition of what is part of gnome and what can use the trademark to us -- especially apps which are not core but on our infrastructure which can use our trademarks -- there is a separate "gnome circle" initiative for non-core apps around gnome: https://discourse.gnome.org/t/official-proposal-how-we-define-gnome-software/3371 -- r-t only responsible for core apps 2. Possible core app changes - want approval from both r-t and design team for changes - currently aday is for design team - CI requirement for core (lack of guidelines currently?) - redundance of some apps in core? (photos? music? ......?) - new text editor - potentially remove file-roller but need to check first if improvements possible? - geary not part of core - potentially add seahorse back? - https://gitlab.gnome.org/GNOME/gnome-build-meta/-/issues/150 - Questions about removing applications from core: this has various implications. We should grandfather in apps that already exist, or have previously been allowed to use org.gnome app IDs and trademarks. -- core apps can use our trademarks, vs circles. Moving can lead to appID changes or TM removal! Technical conditions to enter core: - CI should produce nightly flatpaks - Follow GNOME release schedule / versioning scheme - Dependencies must be approved by release team, requirement to notify r-t -- https://wiki.gnome.org/ReleasePlanning/ModuleRequirements - Quality internationalization (guidelines: https://wiki.gnome.org/TranslationProject/DevGuidelines ) - Aspirational/future: accessibility (guidelines?) especially for custom widgetry - Willingness to work with GNOME design team - Follow official theme - What to do with core apps which lack a maintainer? -- does not necessarily mean it becomes unusable, but e.g. UI/design language and theming changes -- https://wiki.gnome.org/Apps#Maintainers_needed exists; go to d-d-l in such cases? - removing rhythmbox downstream makes Videos become default music player, that's a bit odd - Release team discusses scope of core apps. Seems good to reduce a little bit, while still covering basics (music/videos/files/etc.). But ultimately this should be up to design team. - ACTION: mcatanzaro, abderrahim, alatiera, mclasen to set up meeting with Allan to sync on core app changes 3. Produce GNOME OS images as part of each release for 3.38 - How to test them better? OpenQA? https://gitlab.gnome.org/GNOME/gnome-build-meta/-/issues/206 -- Possible to upgrade using ostree later this week -- Plug-n-play boxes to use latest GNOME will require some changes in Boxes for an ISO image that just works(TM) in Boxes (UEFI support is still WIP) 4. Flatpak runtime ABI stability - Add checks: https://gitlab.gnome.org/GNOME/gnome-build-meta/-/merge_requests/573 - Forward stability? -- Only from one release to the next -- If you add ABI thinks will break as there is no rule that extensions, apps, runtime are in sync/matching -- Never provided fwd compatibility in the past -- If app builds must not be newer than runtime builds you should be fine. Flatpak could be improved here -- Merge ABI checker; currently no ABI checker at all -- Release team agrees ABI checker should verify backwards compat. Discusses forwards compat. mcatanzaro not happy about proposal to provide forwards compat. --- ACTION: Fail with CI for backward compatibility and add a warning for forward compatibility. -- /Try/ to keep fwd compatibility for a year (Pending that Flatpak does things differently) -- if ABI is broken (e.g. CVE fix required), really communicate with the release (also limitations what we cannot do with our runtime) -- Details need to be sorted out on Flatpak mailing list if we want to change this default 5. Flatpak runtime CVE reports - Are we happy with current ones or should we fix? - Current CVE reports here: https://gitlab.gnome.org/GNOME/gnome-build-meta/-/wikis/Release-Contents#master 6. Automation of releases - process still quite manual; mostly historical reasons because scripts based on tarballs. Currently creating releng file with tarballs. Could go via CI but putting on FTP is currently completely manual. - ebassi: Could spin up a container that runs a specific Gitlab CI runner with a specific tag. Also problems with docs (our docs rely on tarballs!). -- ebassi: Latest Gitlab version allows defining a release, publish it, store build artifact (stable location!) and copy to particular CI runner (which could have an HTTP server, internal to our network and not to replace download.gnome.org), running script could then access stable URLs internally. Also stable vs unstable. -- abderrahim: Possible via Gitlab pages in gnome build meta? -- ebassi: Currently cannot move a tarball from one location to another because privileges -- Gitlab runner cannot have access to GNOME infrastructure (security etc). Avoid SSH key in private GL -- ACTION: Make Javier do things! - Releases based on tarballs or git tags? 7. Version scheme change proposal - https://discourse.gnome.org/t/straw-man-proposal-changing-the-gnome-versioning-scheme/1964/57 -- Discussion started off with 20XX but source of confusion; minor version not to be even/odd indicator because uncommon nowadays. Increment main/major version every six months (e.g. 40, 41); for stable releases increase minor version by one (40.0, 40.1). -- Bigger controversies: --- 1) Reducing number of unstable releases (alpha, beta, rc, major.0); --- 2) alpha, beta, rc sorts lower than numbers. Announce to distros 6mo ahead to fix their scripts. -- 3.38 already under new versioning scheme? Likely too late in the cycle. -- "GNOME 4" creates problem of GTK4 expectation (tie / binding to major components). -- Years, but problem is two releases and people often drop minor version when reporting bugs -- Might have to use a ~ tilde for sorting. -- Core apps will have to switch to new version scheme; implications for plugin APIs etc -- Have to adjust freezes (e.g. global freeze) -- https://fedoraproject.org/wiki/Package_Versioning_Examples#Complex_versioning_examples -- ACTION: ebassi to set up meeting to discuss version scheme proposal -- 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.
