Ignoring the technical part of it (i.e. where it will be hosted, what about CI, etc), the area I would like to have some alignment on with The Community™ is the future repository setup, should we ever migrate.
It’s worth keeping in mind that contrary to GitLab, Forgejo does not allow “unbound” root-level repositories. Each repo has to belong to some user or organization.
In the current GitHub world, I would differentiate these spaces:
flathub-infra org which would map directly to something like infrastructure/
flathub/flathub which is a kitchen sink of general issue tracker and target repo of the submission PRs. This would likely be meta/, with separate projects for issue tracking and new apps. Also where flathub-infra/memberships should go.
Actual applications. Probably apps/? Doesn’t fit exactly because there are also extensions and BaseApps over there.
Anyone with strong opinions is welcome to chime in!
Just my 2 cents: Maybe apps and baseapps should go into the same repo (apps/ or packages/), while SDK extensions will go into their own separate repo? (e.g extensions/)
org.winehq.Wine for example is technically a baseapp, but it can also be installed and used as a regular app. Though idk if there are more such baseapps on Flathub.
Given that people will need to register and their usernames all end up in the same namespace, it may make sense to keep the `flathub-` prefix, e.g., `flathub`, `flathub-infrastructure`, `flathub-manifests`, … That makes it easier in the explore page to find the important organizations. At least, for Forgejo’s own developer instance, the organizations are called `forgejo` (main), `forgejo-integration`, `forgejo-helm`, etc.