Wiki: https://fedoraproject.org/wiki/Changes/FilterFedoraFlatpaksAtomicDesktopsv2
Discussion Thread: https://discussion.fedoraproject.org/t/179470 **This is a proposed Change for Fedora Linux.** This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Allow image based Fedora Desktop outputs (and only those), to self-determine if they want to make use of filters on the Fedora flatpak repository for pre-installed Fedora Flatpaks and enable FlatHub by default. If output maintainers choose to enable Flathub by default, they must use flatpak filters to ensure the the Fedora Flatpak remote is used for all pre-installed user applications (the ones pre-installed from the ISO and the runtimes). == Owner == * Name: Jef Spaleta * Email: [email protected] == Detailed Description == With this change, we want to make use of Flathub flatpaks an explicit decision for each image based desktop output (ie. each Atomic desktop). Fedora contributors may package any application as Fedora Flatpak, but those Flatpaks will not be made available immediately to user of the desktops that have Flathub enabled by default, unless they are preinstalled applications. Users that want to have access to all Flatpaks from Fedora can remove the filter or add an additional remote definition that the filter doesn't apply to. === Why not use just use Flathub Flatpaks instead? === Moving the image based Fedora Desktops to using Flathub Flatpaks would potentially require legal work and infrastructure changes. Completely removing the Fedora Flatpak remote from the Atomic Desktops would mean that the default installation would appear very bare bone in terms of available applications. This change is thus trying to reach a middle ground between those two options, keeping Fedora Flatpaks where they are necessary and using Flathub flatpaks to meet growing median user expectation and desire for upstream binary packages for the graphical desktop applications. === Which Flatpaks will be added to the filter? === The list of Fedora Flatpak enabled for the Fedora Atomic Desktops will be maintained by the Fedora Atomic Desktop SIG, with input from the desktops working groups (Workstation Working Group, KDE SIG, etc.) and the Flatpak SIG. We will populate the filter with the list of pre-installed Flatpaks (and the runtimes) in SilverBlue as a starting point. == Feedback == This is a second attempt at this Change proposal after being rejected in the F43 cycle. After some discussion, I felt there was some confusion with regard to intent and benefits of the first attempt and I wanted to take a second pass at this and try to get clarity on some things. The text in this updated version draws heavily from the first in terms of technical specifics. The most material change in this second attempt is to reframe strategic benefit and to clear up confusion and to clarify that FlatHub does _not_ have to be adopted by all image-based desktop outputs. The maintainers of each image-based desktop output are empowered to make a choice to enable Flathub by default or not. We already have a legal decision that its allowed from a compliance standpoint. This is a change proposal meant to make it technically possible to do so with the least amount of friction and confusion to users. There are tradeoffs inherent in the decision on what the default flatpak remote should be. This is why this updated version of this proposal is explicit that its up to the maintainers of each image based output to make the choice as to whether to turn flathub on by default or not. Ultimately its the decision of users to decide which remote they want to use for which applications based on their own requirements. But the entire point of flatpak as a technology is to give application developers and maintainers the ability to decouple applications from the base operating system. We need to create a space for Fedora outputs that want to explore and innovate on the promise of flatpak as a technology the ability to do exactly that..decouple the base os from the application layer. Making flathub the default for a subset of image based outputs makes that exploration possible.. for the slice of users who have self determined that they want to explore the image layer based approach. But because of uncertainty with regard to compliance issues at present we can't cut over fully and we need to make use of Fedora generated flatpaks for preinstalled applications until there is clarity on the compliance issues for pre-installed software by working _with_ Flathub to figure out how compliance concerns can be satisfied in a reasonable manner. == Benefit to Fedora == * Less confusion for Fedora users who expect to use Flathub applications * Less confusion for upstream developers when responding to bug reports about "their" Flatpak'ed application * Stronger focus on what makes Fedora better: upstream contribution and collaboration with other communities * More focus and testing on the Fedora Flatpaks installed by default on the image based desktops == Scope == * Proposal owners: Add a filter to the Fedora Flatpak remote that imaged based desktops could choose to include as part of compose. * Other developers: image based desktop maintainers would need to choose to use the filter and enable Flathub by default in their image composes. This is a choice. Based on discussion I expect at a minimum SilverBlue would choose to make use of the filter. * Release engineering: Should not require any release engineering coordination. * Policies and guidelines: Should not impact any existing policy. Flathub has already been determined to be allowed to be enabled by default, this Change establishes a mechanism to actually do that. * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: This aligns with an upstream first approach for graphical application development and more specifically with the intent of flatpak as a federated technology available for use by open source graphical application developers. == Upgrade/compatibility impact == This change is intended to apply to participating image Desktops users on update. Users that are using Fedora Flatpaks may have to update the filter to keep receiving updates or move to Flathub packages instead. == Early Testing (Optional) == Do you require 'QA Blueprint' support? N == How To Test == Remove Fedora Flatpak remote, enable filtered Fedora Flatpak remote, enable Flathub remote. Commands to be added here. The implementation will likely look similar to previous work: * https://fedoraproject.org/wiki/Changes/Filtered_Flathub_Applications * https://pagure.io/fedora-flathub-filter Once the change is implemented, new installation ISOs for the Atomic Desktops making use of the filter will let users test this more easily. == User Experience == Users of the Fedora image-based desktops that opt-in to enabling FlatHub by default will install applications via flatpak cmdline or from the GNOME Software and Plasma Discover store, and will get FlatHub Flatpaks by default. The set of core applications pre-installed by default on the system will be installed using Fedora Flatpaks and will be defined by the filter implemented as part of this Change proposal. Users of other Fedora outputs will need to enable FlatHub and set up filtering accordingly as a post-install set of user-initiated actions. == Dependencies == == Contingency Plan == * Contingency mechanism: Keep things as is * Contingency deadline: Beta/Final freeze * Blocks release? N/A (not a System Wide Change) == Documentation == We will have to document how to remove the filter or add an additional named flatpak remote definition for users that want to use all Fedora Flatpaks. == Release Notes == -- *Allison King* Senior Technical Project Manager, In-Vehicle OS Red Hat <https://www.redhat.com/> [email protected] <https://red.ht/sig>
-- _______________________________________________ devel-announce mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
