flathub / io.conduktor.Conduktor

https://flathub.org/apps/details/io.conduktor.Conduktor
3 stars 0 forks source link

Access for Upstream #3

Closed Eonfge closed 3 years ago

Eonfge commented 3 years ago

@barthalion Special request directly in communication with the Upstream project.

After publishing it on Flathub, I got back in contact with the Upstream project and they are very enthusiastic. They confessed that it was still on their backlog but that they never got around to it, but that they are very positive about their integration with Flathub. As such, I offered them a shared maintainer role, hoping to further improve our collaboration.

Thus, I wish to propose the following, can we give Stéphane Derosiaux, CTO of Conduktor, access to the repository https://github.com/sderosiaux

This would actually be the first time for me to directly integrate a commercial application, so please let me know if some other requirements have to be met first.

@bilelmoussaoui Was previously also involved in this project-integration, so perhaps he also has some comments on it.

Eonfge commented 3 years ago

@sderosiaux Notifying you directly, feel free to join the discussion. It might be required for you to prove your identity, although I don't think there is much doubt.

sderosiaux commented 3 years ago

Thanks @Eonfge! Glad Conduktor made its way to Flathub thanks to you. We are currently testing it and will document this new way on our website if everything is working properly. (it is!)

barthalion commented 3 years ago

@sderosiaux I have invited you to collaborators. Let me know if I should add someone more from Conduktor team.

I don't think there's anything specific for upstream involvement. Ideally, Conductor should grant us redistribution right so we switch away from extra-data at https://github.com/flathub/io.conduktor.Conduktor/blob/master/io.conduktor.Conduktor.yaml#L62 to "native" module types that benefit from Flathub CDN and ostree incremental updates. As it is, Flatpak will always reach out to Conduktor's servers for downloading the archive and do it from scratch for every, and because URL is unstable, there's a chance it will be not possible to install it until @Eonfge (or automation) updates it.

sderosiaux commented 3 years ago

@barthalion do you mean we should upload our artefact ourselves to Flathub CDN in our CI/CD pipeline, instead of relying on the scheduled job that fetches our URL to see if content has changed? That's do-able, we just need to know how.

barthalion commented 3 years ago

extra-data (as used here) is a workaround to make proprietary applications without upstream involvement available on Flathub. It's basically a wrapper that allows easier installation of unmodified artifacts provided by a vendor, downloaded directly from vendor server to the users' computer. The integrity is ensured by both file size check and checksum, and nothing besides this metadata is hosted by Flathub.

A native download type like Flathub means our CI would extract and repackage your archive, then upload it to our server which uses a CDN by Fastly to ensure it's always installable. There are other advantages like delta upgrades, meaning only changed files are downloaded between versions.

We're in the process of figuring out how to properly allow vendors push directly to Flathub from their own CI, so we may want to revisit that one later.