Convert manifest to JSON

[julianfairfax]

The upstream repo also uses this format. Using the same format is best, because it allows the manifest to be basically the same across the repo and Flathub.

It is also the preferred format by upstream: https://gitlab.gnome.org/GNOME/calls/-/issues/365#note_1951711.

[flathubbot]

Started test build 89444

[flathubbot]

Build 89444 successful To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/72125/org.gnome.Calls.flatpakref

[darkdragon-001]

Thanks for your suggestion!

There currently are quite some substantial differences apart from the format:

• flatpak-external-data-checker annotations for every module
• because of this, we are using newer versions of most dependencies
• because of this, we notice incompatible versions early which we mitigate by creating downstream patches until they are released upstream
• making use of the shared modules Git submodule

This is why it's not possible to easily copy changes anyways.

I personally find YAML much easier to maintain manually and therefore intend to keep the YAML manifest for the time being. Having said that, I would happily hand over maintenance to upstream developers if they change their mind and offer maintaining the Flathub manifest themselves.

[julianfairfax]

There currently are quite some substantial differences apart from the format:

* [flatpak-external-data-checker](https://github.com/flathub-infra/flatpak-external-data-checker) annotations for every module

These don't hurt the upstream manifest, and can stay there or be removed.

* because of this, we are using newer versions of most dependencies

I have an MR to update these upstream, and plan on keeping them up-to-date

* making use of the shared modules Git submodule

The upstream manifest doesn't have to use this, and it's an easy change. There is only one submodule.

This is why it's not possible to easily copy changes anyways.

The changes should be copied from here to upstream, which doesn't need to be done by you.

I personally find YAML much easier to maintain manually and therefore intend to keep the YAML manifest for the time being.

Upstream disagrees, and it would be very beneficial for upstream if the same format was used. I don't think one is significantly harder to maintain than the other, and with the x-checker-data, all the dependency updating is done automatically.

Having said that, I would happily hand over maintenance to upstream developers if they change their mind and offer maintaining the Flathub manifest themselves.

Due to the app being verified on Flathub, I assumed this was already the case. It is something I will have to ask about.

[darkdragon-001]

Summarizing, the format change does not benefit maintaining the Flathub version in any way but it could benefit upstream development.

So if

1. You get FEDC annotations accepted upstream
2. Preferably get FEDC running in their GitLab (maybe sepearate repo with scheduled pipelines and an access key as env secret to automatically generate PRs) as updates happen every couple of weeks so manual updates are not sustainable
3. Have module version updates accepted faster by upstream (in my experience this usually took weeks even if the one in main is broken)

then I am willing to accept this conversion.

[julianfairfax]

You get FEDC annotations accepted upstream

I am working on that. https://gitlab.gnome.org/GNOME/calls/-/merge_requests/713

Preferably get FEDC running in their GitLab (maybe sepearate repo with scheduled pipelines and an access key as env secret to automatically generate PRs) as updates happen every couple of weeks so manual updates are not sustainable

Will ask upstream about this. https://gitlab.gnome.org/GNOME/calls/-/issues/612

Have module version updates accepted faster by upstream (in my experience this usually took weeks even if the one in main is broken)

Working on that. Once my MR is merged, I will try to keep the manifest up-to-date, hopefully with their cooperation.