Looks good to me. More important would be to ensure the continuity of the Fedora Flatpak SIG than this specific RPM spec change. At the current EU OS project status, I cannot offer any commitments. I hope the situation evolves next year.
Cool thanks.
The sidebar discussion Iâm having right now are focused on getting the Fedora Flatpak SIG in a healthier place overall, using the policy process similar to EPEL feels right, its a matter of putting a proposal together and getting stateholder input, including the existing people doing the work and FESCOâs input. Itâll show up as a change proposal in the up coming change proposal cycle if we can get it together.
Hey, no problem. Iâm not expecting you to travel to the past to fix these issues 
I thought to share this so you can hear about the experiences of those who have felt appalled from the community, so that you can (at your volition) ensure that this doesnât repeat it in the future.
Sorry, I must have miscommunicated that. I know SIGs are usually up to the contributor to add themselves, but I meant that, despite putting in a lot of work trying to push the tech forward, I was never made aware of the SIG. I just happened to stumble over it by accident a few days after its creation. Nevertheless, I didnât feel welcome. I didnât appreciate the misinformation, followed by the refusal to elaborate.
I have read the whole thread here and â as of yesterday â the replies to your original toot on Mastodon. Possibly I am too distracted by the partial discussions in all of the replies, so I have a few questions. Feel free to ignore (some of) them if you donât want to share your answers for whatever reason.
What do you think the Flatpak policy in Fedora should be going forward? Does it make sense for Fedora to provide some Flatpaks? If yes, what types of Flatpaks make sense in Fedora according to you?
Do you see yourself coming back to help with Flatpak in Fedora? (Even if itâs not now, but in a potential future moment.)
I think thatâs the wrong question.
I think the best question for this particular contributor is how they can help build flathubâs side of the bridge.
For example, flathub has a very difficult problem with regard to GPL compliance, as a distributor, not just in the runtimes but also in the applications. This is one of the concerns from the changeprosal discussion, which I was following up on back in July.
We are in a difficult spot right now because there have been some very critical deficiencies identified in flathubâs handling of license complinace as part of the change proposal discussion process. It would be extremely helpful if someone who is trusted inside the flathub community to drive the resolution of the critical deficiencies. I can identify them and I can have back channel conversations about them. But as soon as I speak publicly about the specifics, things get weird..clearly.
So what I need is a partner who is understood to be inside the flathub community who can drive public discussion in that community without it feeling like they are being picked on from outside. None of the work that needs to be done is fun work, its license complaince stuff, its stuff that most users donât care about. But its important from a distributor perspective and getting traction on that inside flathub will help more than anything else right now.
Now to everyoneâs credit who responded to the concern I found at GUADEC. It was addressed, it was not ignored. I some difficulty understanding why I was embargod for 3 months over missing license files, so clearly whatever I identified endup being way more work to address than I, or anyone in the discussion at GUADEC, expected.
That issue has been addressed⌠so that gives me hope. But I canât be the one to continue to drive the deficiency discussion from outside like this. I canât be under embargo for 3 month periods every time I find what on the surface looks like a simple oopsie and ends up being a bigger deal once people who understand how flathub internals work start trying to address it.
1 Like
I intentionally tried to phrase that question vaguely. Letâs see if @theevilskeleton wants to add something here. Otherwise weâre just speculating what they might want or not want to do in the future. 
Yes, Fedora should continue to provide Flatpaks, considering there are legitimate reasons to do so, like safely (legally) handling pre-installs and in corporate environments.
However, I believe the scope should be limited to that; probably more limited. For example, apps like media players donât work well in an environment that doesnât have the necessary (nonfree) codecs installed, so these apps will appear broken very often.
Thereâs many documented cases where users believed an interfacing app was broken, without considering legal limitations or even the distributors. As in, the blame is misplaced onto the app rather than something/someone else, which hurts the appâs reputation over a situation they have no control over. So, I would avoid pre-installing media players like Showtime (and thus, not even publish Showtime).
Or, if they are to remain published, At the very least the respective apps should be forked with links changed â of course, the author name should then be âThe Fedora Projectâ (considering itâs a fork), and copyright information should be updated to âCopyright ⌠and The Fedora Projectâ.
(I donât remember if Showtime was pre-installed as a Flatpak provided by Fedora, but I am only using it as an example; I am not speaking on this projectâs behalf either.)
I donât think so, sorry. My first-hand experiences with Fedora Flatpaks developers/packagers and as an upstream developer (Bottles) have burned me out from discussing anything with them productively. I believe it will remain that way, assuming nothing changes. And seeing some peopleâs worryingly hostile attitude towards upstream projects Console and OBS Studio in the past have only solidified my resentment.
2 Likes