Because interfaces are manually connected for a reason, because a snap declaration granting auto-connection takes the user’s voice away at install time and because granting an auto-connection is the store vouching for the publisher, I strongly feel looking at the publisher is an important consideration.
Given that, part of my personal criteria for the health of a publisher and the appropriateness of the request is the publisher’s intent for maintenance. Your point about the unknown future of the snap is valid and for a publisher who said they planned to keep the snap up to date I fully agree and would vote to grant the declaration. If they don’t honor that promise in the unknown future, we could always revoke the declaration at some future date.
In this particular case for this particular snap, I had a feeling that the future was known: and I was right, no one has stood up to claim maintenance for the snap. Therefore if the auto-connection was already granted, there could be an argument made that it should be revoked (since the ‘upstream’ (ie, ev and/or the kernel team) have effectively abandoned the snap). That said, if someone did make that argument today, I would say it is premature since we haven’t seen ‘upstream’ not provide security updates.
As of today, I’m abstaining from this vote. I trust ‘ev’ because I know him personally but feel it would be unfair to give him preferential treatment when my criteria are not being met. I’m happy to discuss this further if needed, but I suggest that other reviewers participate in the conversation.
1 vote in favor
0 votes against
1 vote abstained
Per our processes, this is not enough to grant the auto-connection today. I previously requested other reviewers vote, but no additional votes were cast. Re-pinging to move this discussion along. @JamieBennett, @Wimpress, @tyhicks and/or @natalia can you vote on whether to allow or deny this auto-connection request?