Classic confinement request for GitKraken

Hi there!

We make GitKraken, which is a Git client for Linux. We currently have quite a few issues related to our snap build which we believe would be solved via the classic confinement model. As a Git client, we work with the system git, git lfs, ssh-agent, and gpg-agent. We need access to user files and system files for the git config. We need the ability to run arbitrary shell scripts (git hooks) that can basically do anything that the user has specified on that system.

We expect that with the level of control a Git client would require, the classic confinement would not be unexpected to an end user.

Please note that since your snap was added to the store, we have added a number of interfaces including ones for gpg, ssh, personal-files (for accessing dot files) and system-files (for accessing files in, eg, /etc)?. Have you explored these newer interfaces and perhaps using snapctl is-connected <plug> to provide a better UX for manually connected plugs?

This doesn’t address the issue of git hooks though, and there are other snaps like git-cola that were granted classic for this reason. Note that snaps will not refresh automatically from a strict mode snap to a classic snap. If you still want to pursue classic, what is your plan for migrating existing users?

Ping @GitKraken - this request cannot proceed without the requested information.

Hi there. Sorry about the delayed response. If we were to upgrade to classic snaps, we would most likely ship an intermediate copy of GitKraken that alerts snap users of the change inside the client with the suggested installation method and the reasons for changing. This assumes that for snap users, when they go to install an update, they will get the highest upgrade that they can receive without moving into classic snap. Does that assumption hold? Even if it does not, we could schedule the switch to classic snap further out to allow propagation of the in-app notice.

Further, we would announce the change via our newsletter, twitter, blog, and other various outreach programs we have.

I hope this answers your question, if you have any suggestions for improvement there, let me know!

@GitKraken - thank you for the additional information. If moving to classic, the plan sounds reasonable.

This was left unanswered: "Please note that since your snap was added to the store, we have added a number of interfaces including ones for gpg, ssh, personal-files (for accessing dot files) and system-files (for accessing files in, eg, /etc)?. Have you explored these newer interfaces and perhaps using snapctl is-connected <plug> to provide a better UX for manually connected plugs?

This doesn’t address the issue of git hooks though, and there are other snaps like git-cola that were granted classic for this reason."

We have not explored these newer interfaces. We could definitely leverage those to improve the experience of the current iteration of the snap now that we are aware that many improvements have been made in those areas. Our concerns about shipping a feature complete version of our product would still not be achievable through the snap store even with those additional features.

If we were granted classic confinement, is it still advisable that we leverage as many of the interfaces as make sense for us?

Not unless you want to have different tracks, one strict mode and one classic.

The requirements are understood. @advocacy - can you perform the vetting?

Ping @advocacy re vetting :slight_smile: