[Take over request]: Passing snap to GIMP project

[brunvonlope]

What changes would you like?

Hi. I am one of the packagers from upstream GIMP. Following this note (https://github.com/snapcrafters#how-to-take-over-your-snap), I would like to request, in the name of the project, to I and other interested GIMP devs taking over all the packaging files in this repo and the gimp entry on Snap Store.

Actually both belongs to Snapcrafters, which have been doing a good downstream job by the way but I am personally interrested in making that packaging format official.

We have a WIP branch that creates working nightly snaps on our CI by using snapcraft remote-build (https://gitlab.gnome.org/GNOME/gimp/-/commits/bruno/test-s), since seems to be impossible to build snaps other way on Docker.

For GIMP stable and GIMP unstable (preview), however, I talked with the GIMP maintainer (@Jehan) and we naturally agreed that the ideal would be to releasing these channels in a co-maintenance model like we do in our official flatpak from Flathub: we maintain and decide things about it but we are not alone there if we need for help. Would be nice to have this relation here too.

Any extra information?

So, to summarize, GIMP project would like:

• Change publisher name to GIMP in Snap Store (Can this repo be configured to publish snaps using GIMP's Ubuntu One account?)
• Take owership over these packaging files. This implies in conforming them do our style, principles etc, e.g.: we will remove non-vanilla additions like GMIC for sure and maybe OpenVINO

[jnsgruk]

Hi there! Thanks for reaching out!

Firstly this is a pretty exciting development, and I think having the snap fully adopted/maintained by the upstream would be a positive step for the package and for the users of the snap - many of the issues we see reported at this point are in fact upstream issues and not related to packaging (there are certainly a few packaging issues, but they're being tracked).

Once we agree - the actual transfer of the snap in the Snap Store is relatively simple - and we should probably work toward "Verified Publisher" status if we do that.

On GMIC and OpenVINO - we need to think carefully about this. The last time I looked, there were 300,000+ weekly active installs of the gimp snap, so we should be careful about unceremoniously removing functionality, and perhaps come up with the right way for users to keep hold of that functionality if they move to an officially owned snap?

One route here is through the "tracks" mechanism - we (snapcrafters + canonical + GIMP) could maintain a track such as openvino/stable which builds on a more stripped out "base" snap and adds the functionality - or we could get more creative with things like content snaps - the same likely applies to GMIC.

Let me know what you think.

(@merlijn-sebrechts / @frenchwr this seems like something you might be interested in)

[jnsgruk]

I should also add, any such transition should probably be publicised to your community and ours - we would probably look to a Discourse post or similar if there were going to be any major changes - we made a similar post last week about obs-studio: https://discourse.ubuntu.com/t/a-call-for-testing-major-updates-to-the-obs-studio-snap/64872

[frenchwr]

I agree this is an exciting development!

On GMIC and OpenVINO - we need to think carefully about this. The last time I looked, there were 300,000+ weekly active installs of the gimp snap, so we should be careful about unceremoniously removing functionality, and perhaps come up with the right way for users to keep hold of that functionality if they move to an officially owned snap?

One route here is through the "tracks" mechanism - we (snapcrafters + canonical + GIMP) could maintain a track such as openvino/stable which builds on a more stripped out "base" snap and adds the functionality - or we could get more creative with things like content snaps - the same likely applies to GMIC.

The OpenVINO plugins are already delivered over the content interface - one reason we designed it this way was to minimize the support overhead for the gimp snap. There are a few parts in the snapcraft.yaml for the OpenVINO command-chain scripts but that could be re-worked to be more generic. I guess we could do something similar for GMIC, but I have less experience with that plugin.

[brunvonlope]

Thanks for the feedback .Yeah, if there is some generic way to make content snaps interact with GIMP snap without needing to list them in the snapcraft.yaml that would be really nice. On flatpak, we use a generic extension point on which GMIC and any other plugin can "mount": https://github.com/flathub/org.gimp.GIMP/blob/07ccca7eaab81eacea4ead572953c8931db4294e/org.gimp.GIMP.json#L64

[Jehan]

On GMIC and OpenVINO - we need to think carefully about this.

Just a small comment about why we have this policy: basically we don't want to be in over our head. Our project is GIMP (not more and not less) and that's simply the only thing we want to ship and support. This is why our official package must be as full-featured as possible and no official package must ever contain any third-party code. If we do this, we are basically throwing a message out that these plug-ins are kinda official and therefore it's OK to ask us to support these. We don't want this. And this part is not up for discussion IMO.

Now GIMP is definitely a platform for further development, this is important to us, and both these plug-ins are good plug-ins and probably widely appreciated (the OpenVino one is the AI plug-in by Intel, isn't it?). We'd love it if they could still be shipped for the official Snap, simply separately (and we would not take over maintainership for these! Only for the main vanilla GIMP). As @brunvonlope says, this is possible in Flatpak with the concept of "extensions", and it looks like the "tracks" and/or "content snaps" concepts in Snap may be the equivalent concepts? If so, that's likely what we want.

The last time I looked, there were 300,000+ weekly active installs of the gimp snap, so we should be careful about unceremoniously removing functionality, and perhaps come up with the right way for users to keep hold of that functionality if they move to an officially owned snap?

For sure. If there was a way for people who had the previous version of GIMP to move automatically (at the next update after the maintenance change) into GIMP + the G'MIC + OpenVino snaps, it seems fair. Yet any new installation of GIMP should be Vanilla GIMP only. Then it would be a perfect migration.

I assume that software installers with Snap support would be able to list any "content snaps" (or tracks) available for a base Snap? That's how new users would discover that they can install G'MIC, OpenVino or any other third-party plug-in which wishes to be available for our Snap.

For instance GNOME Software is able to display all Flatpak extensions for our package on Flathub. For instance it is also possible to install G'MIC (and a few other plug-ins, such as Resynthesizer, etc.) for the official Flatpak too, directly from GNOME Software. Simply we don't maintain this flatpak (someone else does and simply uses the Extension point which we make available in our package rules), and it is not installed by default. What we'd like is for the same to happen on Snap, with whatever method is adapted there. 🙂

[brunvonlope]

I assume that software installers with Snap support would be able to list any "content snaps" (or tracks) available for a base Snap?

@Jehan Seems that no yet:

Gravando.2025-07-29.150440.mp4

[jnsgruk]

Not as yet - but not out of the question.

I think whatever happens you'd need something in snapcraft.yaml to allow plugins over a content interface.

Perhaps @frenchwr could take a look delivering GMIC and OpenVINO using just content snaps? I'm a bit short on time over the next few weeks - but I think that's the mostly likely route to be successful.

[merlijn-sebrechts]

@brunvonlope

I talked with the GIMP maintainer (@Jehan) and we naturally agreed that the ideal would be to releasing these channels in a co-maintenance model like we do in our official flatpak from Flathub: we maintain and decide things about it but we are not alone there if we need for help. Would be nice to have this relation here too.

I think that's definitely possible.

I think the best approach would be for us to transfer everything to you, and give you an easy way to contact us if you have more questions or need help. We have a Matrix room that I can invite you to and, depending on the platform, you could tag us if you experience any issues.

That would mean:

• You create a new Snap Store account and we transfer the snap in the store to you
• Your repository hosts the snap source
• Your automation takes over the building and releasing to the store
• We shut down our automation and revoke our access

Is that what you are looking for?

[brunvonlope]

Is that what you are looking for?

@merlijn-sebrechts Last case scenario, yes. On GIMP GitLab CI we have infra for doing that (at least with snapcraft remote-build).

I say "last case scenario" mainly because what I envionsed in the description seems more community friendly IMO.

[merlijn-sebrechts]

@brunvonlope I'm not 100% following. Do you mean that you would prefer the source and build pipeline remains here and only the publisher name in the Snap Store changes?

The main idea is that this organization is just for the snaps published under our name and maintained by us. It's quite different from FlatHub in that regard.

One of the difficulties with how this organization is set up at the moment is that

1. In order to be able to merge anything, you need to be part of Snapcrafters
2. All Snapcrafters can merge in any repository

We can easily change the name of the publisher in the store. I don't think this would require a change in our tooling. But having separate permissions on a single repository in this organization would be difficult with our current tooling, and might be confusing for other Snapcrafters.

I'm open to thinking how we could do something more hybrid like FlatHub does, but I want to confirm first that that is truly what you want.

[brunvonlope]

Do you mean that you would prefer the source and build pipeline remains here and only the publisher name in the Snap Store changes?

@merlijn-sebrechts Yes, that is what I meant.

What would change 🆕:

• publisher name > GIMP (I wonder again if wouldn't be needed another Ubuntu One account, since I don't have much acess to Snap Store UI I don't know)
• owernship/maintainership of the code > GIMP (I don't know technically, however, how this could be done with Github shenanigans)

What would not change 🛑:

• place of the code
• infra

[jnsgruk]

Hmm okay, I also misunderstood. I think splitting it in this way might get quite complicated; I don't know that we can prevent the rest of snapcrafters from contributing to just this snap very easily - and we'd end up with an odd management burden to add/remove "official" GIMP maintainers I think?

It feels like the first thing to do is prove out a way of adding OpenVINO and GMIC over a generic gimp-plugins (or similar) content interface?