I am the maintainer of the unofficial KDE variant (nicknamed Kinoite) of Fedora Silverblue. In short, Fedora Silverblue is an immutable operating system and the recommended way to install applications is to use Flatpaks or containers (podman). Please see the documentation for more details.
As a long time KDE user, I want to be able to install KDE applications on Silverblue/Kinoite using Flatpaks. One way to do that is to publish KDE Apps to Flathub. So I started a call for packaging KDE Apps on Flathub.
I think that packaging all KDE Apps on Flathub will:
give them more visibility,
make new releases easily available to all users on all distributions,
make KDE application development and testing easier as we update the nightly Flatpaks at the same time.
Thus I think that this would be beneficial for the entire KDE community.
Some KDE applications are already available on Flathub thanks to @tsdgeos, @eszlari, @danvratil, @grulja, @mgallien (This is a non exhaustive list. I am sorry if I missed you here). But a lot of them are still missing (list). The Flathub maintainers recommend that developers publish and maintain their own application on Flathub. But so far this has not happen for those missing KDE Apps and this is what this discussion is about.
Thus I suggest that we create a team and tools to share the load of maintaining KDE Apps on Flathub by working on automating updates for new releases. If such a team already exist then I am sorry for stepping on your toes: I did not know there was any.
The first step here would be to start packaging and submitting the missing KDE Apps to Flathub while making sure that the required changes are pushed upstream. In the meantime we could work on automating the manifests updates for new releases. This is made easier by the fact that most KDE Apps are released together at a regular cadence.
To make that happen, I started working on bringing the missing KDE Apps to Flathub and will soon work on updating the upstream nightly manifests as well as automation tooling.
Please let me know if you think this is good idea, if you see anything that may block this from happening or if I should do something differently.
I want to say again that I am really grateful for all the work that has already been done to bring existing KDE Apps to Flathub and that I am not complaining about Apps being missing.
I also did not know that there was already a team of KDE maintainers on Flathub and I would be glad if I could join it instead of creating another team. At the same time, if the current team does not want to take part in the maintenance of the applications I submit, then this is not an issue.
I do not in any case request or implicitly expect that people maintain the apps I submit. I pledge to maintain those apps myself.
I will also reach out the KDE developers for each App I submit to ask if they are interested in co-maintenance.
I am very happy that you want to help improving KDE applications in flatpak + flathub, am I’m very happy with the work you have done so far.
You want to be part of the team, i’m more than happy of helping you become part of it.
But that means respecting our decisions like “we want all our apps to be in json”.
And if you disagree with it, which is a totally valid position, it means starting a discussion of with the team about why it should be changed, not simply ignoring us.
Unfortunately the Flathub Teams link gives me a 404 (I should have mentioned that earlier) which is probably why I did not realize how the current team was organized.
But you are right I was confused by my enthusiasm and forgot about this. I should have asked more questions about the existing team status and asked about how you currently maintain apps.
I also realized that by not wanting to impose maintenance on the existing team I was actually imposing my way of doing things and that was inappropriate.
I am sorry I created such a situation. I have removed all my inappropriate comments from the issue and I have submitted a PR to keep the JSON version for Ark and will update the other PRs soon.
json really doesn’t support comments, now it really seems the parser that flatpak uses doesn’t explode on them. fair enough, but having the explanation in comments in the json is terrible if we want regular users to find them. No regular person is going to go there vs the github flathub page, that is not awesome either, but at least it’s findable via google.
Ideally flatpak would support telling users why we need privileges, but AFAIK that’s just not possible yet
Was wondering, should we ask for a team to be created at https://invent.kde.org/teams to be able to manage “internal” issues? Otherwise i don’t see where we can have a centralized place of the “work TODO”.
Personally I kind of like having this on kde invent - possibly alongside the development repo. I think that makes it clearer that this is a “KDE thing” rather than a “flathub people who like KDE thing” and sets the right kind of expectations about existing practices (like, “bug fixes should go upstream and be targeted at the next stable release to be pulled in to the flatpak”).
I for one would certainly put my work up there - and it would certainly help with ‘meta-KDE’ changes like “get release tags as part of the builds”.
Hmmmm, i think we have different things in mind for the invent.kde.org idea
I was not proposing moving the github flathub repos over there, is that’s even possible?
Or that’s not what you meant with “put my work up there”?
I was “just” proposing having a team page (i.e. like a repo but without a repo) where we could use the issue tracker as task tracker. For stuff like “We need to update Kontact” or “We need to put app XYZ in flathub”.
Or maybe i misunderstood you and you meant something similar?
I absolutely meant something similar. We can disable issue tracking on all the flathub repos and add a readme pointing to the invent page. But yeah, I think that’s just a more natural place to expose the kinds of cross app changes that are sometimes needed but as you say - having the team identified, a clear way to join it and a task tracker would be super awesome.
The only other thing I was thinking (and this is what probably got confused) is that it’d be great to port as many of the review changes that we’ve made to the apps on flathub back over to https://invent.kde.org/packaging/flatpak-kde-applications (and also the other way around, trying to get everything into flathub) but that can be a separate thing.
I like the idea of having a dedicated repository act has a central point to track cross apps issues / TODO lists. I don’t have an opinion on whether this repo should reside in Flathub or KDE Invent. However I don’t think that disabling issues on all Flathub repos will be practical as we will still have PRs on Flathub and it will probably be less practical to constantly switch between the two.
Yes, both of those are definitely on my TODO list. I started updating the upstream flatpak for Ark but I have yet to do it for the other apps (and the Ark one needs to be updated again).
