We aim for neon to be the reference of what a KDE software experience should be. There certainly is a problem with developer time available for neon currently, so the goal's target of getting more people on board seems reasonable enough. We are however a bit concerned that the goal champion has not yet reached out to the existing neon developers. It's also a bit unclear how the goal is to be achived exactly. Callling neon the official distribution won't magically make it that.

It seems it needs a timeout longer than 1h
https://invent.kde.org/jriddell/snapcraft-kde-applications/-/jobs/415972
Is that possible? When I set it to 2h it seem to get ignored.

The snap builds are still getting stuck on launchpad credentials.
https://invent.kde.org/packaging/snapcraft-kde-applications/-/jobs/415906

https://invent.kde.org/sysadmin/ci-images/-/merge_requests/50

It doesn't seem very happy with the LAUNCHPAD_CREDENTIALS contents for some reason. I twiddled it so please add two variables with the relevant parts from within that file:
LAUNCHPAD_CREDENTIALS_ACCESS_TOKEN
LAUNCHPAD_CREDENTIALS_ACCESS_SECRET

In T11034#278782, @bcooksley wrote:

Is the intention for the Snap definitions to continue to live in a central repo (vs. say the actual app repo)?

mfederle has been awesome and made some CI for it that seems to work so I've merged it into
https://invent.kde.org/packaging/snapcraft-kde-applications/-/blob/Neon/release/.gitlab-ci.yml
https://invent.kde.org/packaging/snapcraft-kde-applications/-/blob/Neon/release/Dockerfile

Can we just use launchpad.net which has a feature that you can use snapcraft remote-build and it'll upload the snapcraft.yaml file, build the snap and let you download the resulting snap binary?

I spoke to the Snap devs who don't recommend it. Snap needs systemd and docker doesn't work well with systemd they say. It's also little tested. Having said that they believe that Visual Studio snap is built with Docker so it's not impossible.

This isn't currently within the scope of KDE