Space isn't too much of an issue on cdn.kde.org:

Filesystem                Size  Used Avail Use% Mounted on
/dev/md1                  1.9T  1.2T  631G  65% /
none                      492K  4.0K  488K   1% /dev
/dev/mapper/vg0-archives  4.9T  1.6T  3.4T  32% /srv

We just have to ensure that they are expired in a reasonably efficient manner (and with some kind of sensible naming convention that is scalable). Discussing how to implement all of this is probably best done elsewhere though rather than here.

No code commits on Kube in 6 months. Is anyone still working on it? https://invent.kde.org/pim/kube/-/branches

Moved to GitLab issue https://invent.kde.org/teams/flathub/issues/-/issues/23 as it's more visible than an old Phabricator issue.

This is all handled in Gitlab with CI job logs displayed easily for Flatpak builds. Flathub has it's own build page where you can see build status as well. As for AppImages they're not centralised anywhere so no real infrastructure to speak of. Snaps I'm not certain of, perhaps @scarlettmoore can weigh in there.

This is all now handled on Gitlab so closing.

Snap has been created but is out of date @scarlettmoore
Flatpak is on Flathub and up to date
AppImage doesn't really have a centralised place to store them, and thus distribute them from.
If we want a central AppImage repo for KDE apps it could be hosted on cdn.kde.org but as they can be quite large due to bundling many libraries I'm not sure what the space requirements would be for them or how much space we have @bcooksley

Makes sense to me too, but I've seen many projects that have taken ownership of the flatpak recipe to let it degrade over time. We need ways to make sure it doesn't happen.

Flathub builds a Skrooge flatpak from its own spec at https://github.com/flathub/org.kde.skrooge/blob/master/org.kde.skrooge.json , and kdeapps checks Skrooge's git master every day for changes and builds using https://invent.kde.org/office/skrooge/-/blob/master/org.kde.skrooge.json .

thanks! this is the first commit that I actually got around to setting arc up properly and landing myself. so thanks!

Thanks.

+1 good stuff!

The Skrooge Binary Factory jobs have now been regenerated and will use the new configuration going forward.

Commited

I'm going to close this since the qt 5.10 branch of the flatpak sdk is now "unmaintained".

Works for tarballs, good enough.

Not needed anymore

Sure

Let's leave this branch die with Qt 5.11. Users should be moving away from it anyway.

Thanks!

5.12 is enough for *me*.

It's qt5.10 branch

Same as 5.9, works for me if you really need it, but I wouldn't be putting new things there.

For which branch is this?

Right, for master and stable (currently "3.2").

Just to be sure, you want to have it built both for master and specific branches?

@apol Thanks, adding another nightly for other branch was my initial though. Can we add this? We would be done then.

And doesn't the nightlies we have now already tackle this?
https://phabricator.kde.org/source/flatpak-kde-applications/browse/master/org.kde.kexi.json

Yes, Ben summarized what I meant. Thanks. We're not yet there (that is, production-ready flatpack or app store of any kind, with QA and regular contributors). We can't have all of this the day one, we need nighties so would-be contributors who are not developers have the chances to test current software (stable/unstable). Current state is that many contributors (power users) run 1 or 2 years old software so even initial conversation within bugs.kde.org is problematic.

With regards to the Windows Store - the work by myself and Hannah only extends to publishing on the Binary Factory. Validation of a working application, and then publishing as part of a release (on download.kde.org and the Windows Store) would still be up to a maintainer as part of their release work.

In T10377#174777, @apol wrote:

In T10377#174613, @staniek wrote:

Thanks Aleix. I'd like to understand: you are not planning it but do you see some rejection by principle or by technical reason?

I'd say it's not very practical. But we could do it if necessary.

Bottom line is that for Windows there is no such split and stable software "by KDE" has chance to be shipped.

I'd say going all the way on Windows stable releases would mean to get the application on the Windows Store. It should be the maintainer who does that.

With regards to Windows, we do have both unstable nightly builds (which the Binary Factory produces for many projects) along with stable builds (which the Binary Factory also produces).

In T10377#174613, @staniek wrote:

Thanks Aleix. I'd like to understand: you are not planning it but do you see some rejection by principle or by technical reason?

Thanks Aleix. I'd like to understand: you are not planning it but do you see some rejection by principle or by technical reason?
Bottom line is that for Windows there is no such split and stable software "by KDE" has chance to be shipped.