flatpak.github.io
flatpak.github.io copied to clipboard
Policy for adding distros to Quick Setup
39/60 issue tickets are requests to add a distro to the Quick Setup page. I think it would be helpful if there was a policy to keep these to a minimum, such as requiring a PR instead of just asking for the core team to do it. Maybe some sort of notability requirements, such as a ranking on distrowatch?
This sounds like a good idea to me. It is true that we already have, for example, two small local Turkish distros (and a PR for third one currently opened) in the list, and some other not much popular distros.
@barthalion What is your opinion about this?
Categorize it?
I see little value in listing all the different Debian based, Fedora based, etc.
Or maybe group them into the mainstream distros and then have one section with 'Others'
Edit: See, that this issue already exists
How many, for example, Fedora distros we have in the list? I see only one. RHEL and CentOS are different brands. Also, I don't see any point in categorizing distros just because they are based on something. Every one of them has a slightly different Flatpak setup process.
Maybe some sort of notability requirements
On second thought, I think gate keeping based on distro size is going to put people off. One of the downsides of Snaps is that support for other distros is just a marketing bulletpoint.
Categorize it?
TBH, the only distro that matters is Ubuntu. Virtually everyone else supports it out-of-the-box or uses Gnome software. Hell, we could just list a packagekit command, this is more of a propaganda tool than anything. Just list the top 5 sexy distros and link to a filterlist to display the rest.
The main motivation for this ticket was to redirect user energy away from filing useless issue tickets that will never be acted upon to PRs that require minimal review.
TBH, the only distro that matters is Ubuntu.
Sadly, Ubuntu has probably the worst Flatpak support and focuses only on Snap officially.
Sadly, Ubuntu has probably the worst Flatpak support and focuses only on Snap officially.
Right, but that's why it has a prominent placement in quick setup. A dedicated "other" page with the packagekit install command at the top and a filterlist of smaller distros would be ideal IMO.
Here are my ideas for a policy :
- Distros should be relatively known
- Distros which are variants of others should be notably different as to make the guide provided invalid
- Distros should have a certain amount of history with exception of very notable new distros (the family of new RHEL clones come to mind as notable but the CentOS guide fits them so see previous clause)
- Distros should have a clear known team of people
- Distros should have a known policy when it comes to update flatpak itself
If we add the criterion of existing in DistroWatch's database, that alone would disqualify Future OS and Sulin OS, though not Pisi. DW explains their criteria for inclusion here: https://distrowatch.com/dwres.php?resource=faq#newdistro
The search pages for flatpak on Distrowatch or Repology show that there are many distros that have packaged it by now. Since Flatpak is well-established among distro packaging the criteria for distro addition can be strict.
I don't really like the idea of existing in DW's database as that's external. I think we can just take this DW criteria and we get essentially the same rules (and more) :
- Distros should provide some basic infrastructure such as a website, documentation, a way for users to get support and a method for reporting bugs.
And I think that "embedded distributions or very niche specialist distributions" and "projects which are available only on cloud services" would already not be included because of my first and second criteria.
As for being strict, I think that the criterias I've listed are enough of a barrier for now at least.
Sadly, Ubuntu has probably the worst Flatpak support and focuses only on Snap officially.
Here is a ticket about adding Flatpak support to the Ubuntu GNOME Software fork: https://bugs.launchpad.net/snap-store-desktop/+bug/1950158
If this was implemented, it would still be far from being ideal (Flatpak would still need to be installed first using CLI, flatpak/xdg-desktop-portal* packages would still be outdated in LTS releases etc.), but it would be a good progress.
Here are my ideas for a policy :
* Distros should be relatively known * Distros which are variants of others should be notably different as to make the guide provided invalid * Distros should have a certain amount of history with exception of very notable new distros (the family of new RHEL clones come to mind as notable but the CentOS guide fits them so see previous clause) * Distros should have a clear known team of people * Distros should have a known policy when it comes to update flatpak itself
KaOS is independent and does fulfill all these points
I try to add it since years
Is this really how long it needs to take to add a simple entry to the list?
I try to add it since years
Where have you tried adding it? I see that you've commented on an issue here which is about a year old
Is this really how long it needs to take to add a simple entry to the list?
I don't think anyone should be forced to work on anything. I would agree that it should've been reviewed (and probably accepted) if there was a pull request but that's not the case. I'm happy to see that the information seems to have been gathered though but it is one of about 27 similar issues.