On the desktop team, I’ve been working on snapping the gnome-3-24 platform for use by other GNOME app snaps. The platform snap is in the store (edge) now and we are starting to snap GNOME apps using it. The gnome-3-24 snap is owned by canonical and we will support it.
The question here is, which app snaps do we want to officially support and which should be community snaps? I have the gedit snap ready for the store now.
As we get more and more GNOME apps snapped and the snapcraft.yaml files improved, moved over to use the platform snap, etc then we’ll be asking the upstreams to include the yaml in their trees and push to the store directly from CI. Once they’re ready to do that we can transition ownership. In the meantime I think we should use the snapping process to work out the bugs in the launchers, platform snap etc etc - so it will be easier for us to own them for the time being.
So I think we should continue with apps like gedit, and then work on the core GNOME apps for music, photos, maps, calendar, and so on.
Defining which snaps are maintained by Canonical and what that really means seems like a topic we can cover in the next product sprint in July.
We can already try to define a base line, though. At a bare minimum, it sounds like such snaps need to be maintained by a well defined group of people, with a clear plan including security updates, and under known terms which include what level of support is offered and for how long. Without any of those we can’t really claim the snap is supported.
If we have that for a snap then it seems fine and somewhat expected that it’ll be published under the organization account, and ideally we should make those terms and processes more clear. If we don’t, then it feels more like a personal initiative without a stronger commitment from the organization, and might be published under the personal account, at least for the time being.
This is something we already do on the desktop team. We have a package set of packages we as a team maintain. The apps we are snapping are apps we already support in the distro. I think it makes sense for us to maintain those snaps with the same level of support as we do in the distro.
That’s a great idea! It’d be fantastic to have that available and up-to-date. I suggest just having that list and the process surrounding those snaps more formally organized then. For example, what’s the full list of supported snaps, what are the terms, where is snapcraft.yaml for each snap, who to talk to, etc. If you already do the maintenance work, we don’t need much more bureaucracy around it. Even a wiki topic here in the forum which you can collaboratively edit with the details might do it.
Having them owned by an Ubuntu team rather than Canonical might make sense there. Do you know what the status of using snaps from other providers through content sharing is? Is any user/team going to be able to auto-connect and use the GNOME platform snap as published in the store today?
As published today, no, but you need only request a snap declaration. Please follow Process for aliases, auto-connections and tracks in a new thread.
Not sure if we have a consensus here, if so I can register the gedit (and other) names in the store for canonical for now. If we prefer going the “ubuntu” publisher route we need to talk a bit more, there is currently no ubuntu publisher but for those applications it probably makes sense to create one.
@mvo Not sure either… I made a few points above about the details we want to write down for having some sanity around this process. I haven’t received any feedback after that. Do we have that in place already?
@seb128 The underlying mechanism supports that, but we need some more details about how the content being offered is organized and what the maintenance plan is so that people depending on that snap won’t have their workloads suddenly broken.
Per @jdstrand’s note, a new topic with details would be the next step.
