Stepping Down Gracefully

by Alan Pope on 25 September 2020

The Snap Store has been designed to enable upstream developers and enthusiastic community contributors to publish snaps. As with most Linux packaging solutions, the wider community are often responsible for starting and maintaining software packages. This is a double-edged sword, especially for humans with limited life spans and other shiny things to steal their attention.

If a community contributor decides to move on from maintaining software packaging, has too many other things on their plate, or life just gets in the way, it’s not necessarily a problem. Users are appreciative that someone packaged up their favourite application, but can get upset quickly if that software is no longer updated. Snap publishers who are overwhelmed or busy doing other things have some options here.

Automate yourself out of existence

We recommend the first course of action is to ensure snaps are published via automated tools to reduce manual steps in the publishing workflow. Using the snapcraft build service or 3rd party tools such as Travis or Circle CI will reduce the workload on a typical snap publisher. A well crafted snapcraft yaml will often result in automated builds getting published in the edge channel before the publisher even notices. All that’s left for the publisher is to test the edge build and then publish to beta, candidate or stable channels as appropriate.

Share the love

The Snap Store has a concept of “Collaborators”. The responsibility of maintaining a snap published in the Snap Store can be shared among a group of people. The maintainer of a snap can invite others to share responsibility over the publishing, metadata maintenance and release of a snap. The list of collaborators can be managed in the Snap Store web dashboard. This can help to easily spread the load.

A peaceful handover of power

When the maintainer of a snap has decided to focus on other things, we can handle that too. Where possible, we recommend snap publishers transition their applications to another individual or organisation rather than let them become outdated. Ideally snaps should be published in the Snap Store by the upstream project. So the first port of call would be to offer to transition the snap upstream. Sometimes this isn’t possible if the developers are unable to take on the additional workload themselves, however small that might be.

Alternatively we recommend seeking out another enthusiastic, trustworthy community member to take on the mantle of maintaining the snap package. Often just starting a conversation on the upstream issue tracker, or in their real-time chat of choice will yield good results. Someone keen may even be found within the wider community of the upstream project.

If that fails, a further option would be to find someone within the snapcraft community. There are a group of dedicated snapcraft enthusiasts who love the challenge of maintaining new snaps, and taking on existing ones if necessary. They can be found in the snapcraft forums. Start a new thread, looking for a new maintainer, and typically one can be found.

Once a new maintainer is found, the transition from one publisher to another can be actioned via the forums. Start a thread in the store-requests category indicating who the snap(s) are moving from, and who to. The store admins team can do the necessary validation checks behind the scenes, and move the snap(s) to their new home. It’s then up to the new maintainer to hook up whatever build or CI system is needed to seamlessly continue publishing of the snap.

Note that when a snap is transferred, by default the previous maintainer is kept as a collaborator on the snap. They can continue to be involved but without being named as the publisher, or they can be removed as a collaborator, and no longer maintain the snap.

So the take away from this is, if you’re feeling overwhelmed and need to offload maintainership of snaps to others, don’t panic. We can help, and our community can too.

Photo by Osman Rana on Unsplash