Everything in Fedora takes time. I wouldn’t worry too much about whether a change lands in Fedora 44 or Fedora 45, because Fedora 45 will be here before we know it. Another 6 months simply will not matter in the long run. (Even if the proposal is approved today, we probably wouldn’t actually be able to implement it in time for Fedora 44 anyway!)
That said, we certainly also do not want change proposals to get stalled.
Indeed.. I’m not concerned about this getting rejected.
I’m concerned that it did not receive a vote at all.. especially when the first vesion of this did.
Having the vote on record and which members of Fesco voted which way is material in terms of taking a 3rd bite at the apple.
The lack of a vote is both disappointing and concerning for me.
If Workstation has agreed to implement a filter on Fedora Flatpaks but not yet to enable Flathub, then what is the proposed replacement? Fedora RPMs? Or are you only planning to go forward with filtering out Fedora Flatpaks if you can later change the priority to favor Flathub?
Here’s what you are missing in terms of capability…
You can define 2 versions of the fedora flatpak remote.. named differently but pointing to the same oci registry.
One of those gets the filter and its on by default.
The other one without the filter is disabled by default and users can choose to enable it.
In this situation what you see by default is just the subset of things allowed by the filter and users can enable the full remote.
In the alternative situation where there is no filter and workstation gets its own dedicated registry url… that workstation registry is on by default the the full fedora flatpak remote is disabled by default. User chooses to enable it or not.
In either situation the user has multiple remotes installed, one of them is enabled by default, the other is disabled by default. The user chooses the remotes to enable to increase the available software.
We can do either of these without enabling anything at flathub by default.
I understand all that, but I don’t think it creates a good default experience for users if the software store is empty by default. If the default setup is
then the only other apps available to install in the software center are
So that’s what I was questioning.
From this Change Proposal’s 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.
I should amend that to make it clear, subject to existing FESCO policy.
If and when FESCO decided to allow it by policy, this filter is a mechanism by which outputs can still meet legal obligations for pre-installed application.
If there is FESCO doesn’t allow it to be enabled by default, then users choose which sources to enable, including the full fedora flatpak repo.
I think there are many expressions of what a default user experience is best. I think that’s why we have different editions and spins already. its perfectly fine if you and I disgree with the opinions of the maintainers of a specific output. we aren’t offering a single output that expresses a single default user experience. If we did that, this would be a very different project.
I’ve made a material change to the wiki proposal that is intended to express 2 clarifying refinements from the corpus of this discussion.
A clarification to make it clear that the intent flatpak verified floss subset by default as I have communicated here.
To describe an additional compromise decision where FESCO allows outputs to opt-in to the filtered default remote such that outputs would be allowed to treat both the full fedora flatpak remote and the full flathub remote as user-enablable. Essentially resulting in an output that was able to update itself, but the user made an explict choice as to which remotes to select for additional software.
The very fact that the discussion has continued for so long is indicative that there is no consensus on this topic. Therefore, continuing to force the issue is only causing divisiveness and diverting time and energy from efforts that actually benefit Fedora.
As I have previously stated on numerous occasions, the proper solution for allowing those that want to prefer Flathub content over our own is for Software to have a configuration dialog for enabling/disabling/reordering software sources. (Discover already has this.)
At this point, the right thing to do is withdraw the proposal, accept the feedback that has been given here, and not seek “a third bite at the apple”.
If this change proposal is not approved by FESCo, or if approval is further delayed, may Fedora community members contribute comprehensive guide to the official Atomic Desktops docs that explains how to customize the Flatpak setup—including detailed instructions, examples, downloadable config files or scripts and GUI screenshots for manually creating and enabling filters on the Fedora Flatpak and Flathub remotes?
Of course you can contribute documentation. Documentation is not controversial.
I disagree.
I don’t think every decision that can be made or should be made can get to consensus. I think sometimes you have to make a space for people to agree to disagree and let them do their work in their respective corners. This is likely one of those situations. Which is why this proposal is explicitly about letting outputs opt-in.
I’ll go further and say I think contention can be gamed to the benefit of the interests that benefit from the status quo. And I am deeply concerned about that generally.. especially for a project that is suppose to be innovative.
So everyrone should expect me to take a 3rd bite and a 4th bite and maybe even a 5th bite or a 6th bite at this… every time attempting to address a concern from the previous round that prevents us from making it possible to take a stronger upstream first stance for Fedora outputs that want to do that. And if the goal posts shift, I’m gonna call it out. I don’t think that’s happened yet.
With that said, if this gets rejected I will be following up with specific FESCo members about specific deficiencies that would need to be addressed in order for us to get to the point where fedora outputs can opt-in to using FlatHub verified floss subset. I’ll write that up publicly for us to discuss.. about what consensus opinion is about what it will take to get us there. Not whether we should or not… but what it will take to get there.
I’m not going to step back from the controversy just because it’s controversial… i’m going to lean in and work through the problem persistently using the processes available to me.
Thanks for updating and clarifying the proposal and for responding to all the feedback. I appreciate it. I find the compromise proposal somewhat less objectionable, but I am still stuck in my opposition to the idea that Fedora Flatpaks are inherently inferior to Flathub and users therefore need to be protected from them, given that they are built from the same sources as our existing RPM packages and are subject to the same guidelines and standards[1]. Also, as far as I know, a mechanism/user interface for providing an equal choice of the two flatpak remotes (Flathub and unfiltered Fedora Flatpaks) does not currently exist, so it would have to be developed if the Change + compromise approach is approved.
The only exception is maybe software that relies on patent-encumbered codecs, since the Fedora Flatpaks cannot rely on addons from third-party repositories like the RPMs can. ↩︎
Hmm…
why are we talking about the language of superior/inferior? I think that’s something your bringing into the discussion.
There is a choice of remotes. Flatpak as an application platform that delibrately separates out the base OS from the application layer. There is no technological reason to prefer one remote over another. That is a fact without judgement as to quality of either.
The flatpak technology as implemented currently doesn’t fully anticipate the complexities of what happens when you have multiple conflicting remotes enabled at the same time. There is no optimal user experience which deconflicts remotes fully so that you can install variant applications from both in a reasonable manner. And as a result default choices still need to be made, turning both remotes on without any sort of filtering is a poor experience.
One of the remotes as a concept of a verified floss subset.. exposing that subset regardless of quality to users by default is in line with this project’s principle of taking an upstream first approach as much as possible. The other remote has no such subset afaict.
I could argue that an expansive reading of the existing packaging policy concerning justification of downstream patches which is supported by the principle of upstream first would imply that anytime we are not preferring the verified upstream flatpak that should require an exceptional justification process.
The proposed filter is an implementation of an exceptional justification process that makes it possible for outputs who want to take an upstream first view of flatpaks can do so… in an opt-in manner.