Hello,
ksnip has finally reached snapcraft but we still have the issue that users need to connect to kde-frameworks in order to use it, which, I believe will lead to bad reviews and users assuming that something is not working.
Can you please autoconnect ksnip to kde-frameworks-5-core18?
Thank you for your support!
I’m +1 on granting auto-connect to the content snap in question (that’s the main point of content snaps, right?). Also as mentioned in Autoconnect 'office20' and 'abstractgames' to kde-frameworks-5-core18.
Thanks Daniel, anyone else?
I’ve started getting first Issues complaining about the snap not working 
Same here for us (office20 and abstractgames)… It seems like we’re the first people to ask for this.
Is it possible to get some attention from more reviewers so we can proceed to release stable?
I think @kenvandine or @sergiusens might want to weigh-in here, because I’ve been warned-off from using the kde-neon extension and the kde-frameworks-5-core18 content snap before for reasoning that they are not for wide consumption. I am under the impression that they are specifically for the kde project’s own snaps only, which is why the content interface is not asserted within the store for automatic connection by random snaps that want to use it.
I don’t think this is the case (anymore), as far as I know, @jriddell was going to seek auto-connection for the kde related content snaps.
aah, ok, thanks for updating 
I +1 auto connection.
@sergiusens thanks for the support.
Today is a week since I posted the request, we have 2x 1+, is the request now granted? Whats the process from here on?
I think it just needs intervention from someone like @roadmr
Hello,
Per Process for aliases, auto-connections and tracks the usual waiting period is 7 days (it might be somewhat longer due to queue length - sorry about that), meaning someone should get to it soon.
Please hold on. kde-frameworks-5-core18 is owned by another publisher (the KDE project) and that publisher has not requested auto-connection for the world and unlike the gnome content snaps, there is no statement from them stating their pledge to not break consumers (this is completely within their right-- it is their content snap to be used by their snaps).
@roadmr - the point of content snaps is to have them auto-connect from the same publisher, not arbitrary publishers. For arbitrary publishers, we either need a global auto-connect or both sides need to acknowledge the risk (which is not good for users if both sides say “sure, I’m fine to break/break you”).
For all the same reasons as discussed in lyricfier, I vote -1 to auto-connect this interface. ksnip could easily break at anytime since the kde team has not declared to not break consumers and the store granting this would be inappropriate since that would be the reviewers vouching on the store’s behalf that ksnip won’t break. As reviewers, we can’t make that guarantee and it would be unfair of us to place that burden on the kde team or ksnip’s users.
If the kde team wants to seek a global auto-connection, that should be done elsewhere. Otherwise, ksnip should probably instead use kde-frameworks-5-core18 as a build snap or fork it. In this manner, the ksnip publisher can release on their own cadence and QA and not risk breaking its users.
@jriddell - can you comment on your intent to seek global auto-connect for the kde-frameworks snaps?
@reviewers - please note, auto-connecting the content interface between arbitrary publishers is not typically allowed. Please see Process for aliases, auto-connections and tracks (“auto-connection request considerations”). For those that have voted in the affirmative, please justify why you feel this request is unique and should be auto-connected.
@jdstrand Kind of sad to hear that. I’m not involved in the snap philosophy so can’t argue with you but for me your comments mean stopping snap support for my application. I haven’t released stable yet and I’m already getting issues from users complaining about the snap not working and there are probably some of them who already abandoned my application as the first contact with it was an error message about missing dependencies. In it’s current state, it’s just bad user experience.
@jdstrand
Is the alternative in a case like this to add the kde-framework snap to stage-snaps?
Note: I talked to @jriddell on Matrix and he said he’ll request auto-connection for the kde-frameworks-5-core18 snap tomorrow, so that should solve the issue of ksnip and every other snap using this content snap.
@galgalesh thanks. I hope this works out and resolves our issue.
Note, that the kde publisher is going to request a global auto-connect so this request will be unneeded when it is granted.
That said, I may have not been clear. If you plug another publisher’s content snap, they are under no obligation to not break your snap by changing ABI, etc, so the default policy protects you and your users. You as the ksnip publisher are under no obligation to plugs another publisher’s content snap so you are free to do what is needed, including forking the other publisher’s content snap or using it as a stage-snap. In that manner, you can control updates to your forked content snap or your snap that uses a stage-snap and not break your users if they happen to get a breaking update to the other publisher’s snap. This provides a robust user experience as opposed to a potentially unreliable one.
Again, it sounds like the kde publisher (the one that publishes the kde-frameworks-5-core18 snap) is going to pursue a global auto-connection which will include them stating they will not break consumers like ksnip, which will allow you to trust that your snap won’t arbitrarily break.
