Process for aliases, auto-connections and tracks

[niemeyer]

@jdstrand Thanks for formatting it nicely. Would be nice to have that process as the first message of this topic, so people getting into it will see the actual approved process upfront.

[jdstrand]

@niemeyer

Would be nice to have that process as the first message of this topic, so people getting into it will see the actual approved process upfront.

I’ve done this just now.

[roadmr]

One more request. Could the first message be updated to reflect the fact that this process also applies to track requests? So far I’ve been informally pointing people to this post and just saying “this also applies to tracks despite what the process specifies” but it’d be nice for that to be formalized.

Thanks!

[jdstrand]

FYI, I did this yesterday.

[morphis]

@jdstrand @niemeyer Is it possible that we can one or two people from CE into the list of reviewers to speed up reviews for certain commercial things?

[jdstrand]

It is of course possible; I’ll leave the decision to @niemeyer if we want to do this.

My question is what in the existing process is causing trouble? You asked on this thread and I saw in another thread you wanted to speed up the one week waiting period. The one week waiting period is in place so reviewers have a chance to vote (ie, we want to support the case where 2 quick ‘yea’ votes are cast and then a ‘nay’ vote later). There is also a process for architects to waive the waiting period. Is this not sufficient for your needs?

[niemeyer]

@morphis @jdstrand Everybody is welcome to review, but we need at least two reviews from people that are sitting here all the time and reviewing things all the time and that remain aware of current practices. Having someone sporadically reviewing and mainly when they want things in quickly feels like a recipe for bad reviews.

[jdstrand]

I’ve been meaning to investigate/document this for a while-- reviewers need not worry about granting an alias that is used by other snaps or an alias that is the name of a snap. snapd will prevent inconsistencies:

• if a snap is installed with an alias, then installing a snap with the name of the alias (ie snap install <alias>) results in the snap being uninstallable until the alias is removed with snap unalias <alias>
• if a snap is installed that has an automatic alias that matches the name of an already installed snap, then installing the snap with the alias results in the snap being uninstallable (this may be a bug, but it is safe)
• if two snaps have an automatic alias with the same name, the second snap is not installable until the first’s alias is removed with snap unalias <alias>

[niemeyer]

I have polished a bit the topic and moved it into the documentation category.

In the process, I’ve also removed @jdstrand’s historical problem description from the post itself.

Here is the content for posterity:

@jdstrand

Problem description from original posting

As a store reviewer, I have the ability to grant auto aliases and auto-connections, but the process for approving those is undefined. The story was quite nebulous for a while with reviewers just trying to make the best decision in the moment. Today developers are being asked to make their requests via the forum (great!), but it isn’t clear (to me) when I may grant the request.

I can say a few criteria I consider before expressing my opinion in the forum (but I’m not asking to define all the criteria now; we probably need to work with the process for a while to see what falls out of the discussions before codifying the criteria):

For auto-connections:

• for the public store, I look for the ‘officialness’ of the publisher of the snap because granting an auto-connection means that the public store is vouching for the publisher’s intent (maintenance, security updates, etc) and snap implementation (it does what it advertises, works well, etc) to the degree that we remove the user’s initial choice on connection at install time (the user may of course disconnect the interface after installation, but the snap may have already taken advantage of the connection, which is an important consideration (and why we don’t auto-connect everything in the first place!))
• for the public store, I look for the ‘reasonableness’ of the request. Eg, a ‘top-like’ program will necessarily need the ‘system-observe’ interface but not ‘network-manager’

Similarly for auto-aliases:

• for the public store, I look for the ‘officialness’ of the publisher of the snap since putting the aliased commands into the user’s PATH implies a certain level of trust in that command (and the publisher)
• for the public store, I look for the ‘reasonableness’ of the request. Eg, do these commands make sense for the snap (eg, auto-aliasing a ‘mysql’ command in a LAMP stack snap is probably not great considering there is an official ‘mysql’ snap that provides this command)? do these commands exists elsewhere? Are they overly broad (eg, ‘editor’)?

To that end, I’ve expressed my opinion in a few forum requests and have waited on people’s opinions in others. Thus far, I’ve only acted on a few where there was a discussion with clear outcome. What I’d like to see from this post is:

1. who is allowed to vote on the request?
2. how many votes are needed to grant the request?
3. should the vote be unanimous? if not, what majority percentage wins?
4. is there ‘veto’ power? if so, who has veto power?
5. what is the process for revoking a granted auto-alias or auto-connection?
6. anything else?

[kyrofa]

So apparently myapps-reviewers is going away. In light of this, who are “reviewers” with regards to this topic?

[jdstrand]

@kyrofa

So apparently myapps-reviewers is going away. In light of this, who are “reviewers” with regards to this topic?

The current ‘myapps-reviewers’ from LP are:

• @sparkiegeek
• @popey
• @noise
• @cprov
• @roadmr
• @ratliff
• @evan
• @JamieBennett
• @jdstrand
• @kyrofa
• @Wimpress
• @mvo
• @natalia

IMO, the new forum group/team should consist of these people.

[Lin-Buo-Ren]

I would like to ask if the @reviewers group really exist? Directly clicking on the tag gives an “Access Denied while trying to load /groups/reviewers.json” error.

[jdstrand]

@Lin-Buo-Ren

I would like to ask if the @reviewers group really exist? Directly clicking on the tags gives an “Access Denied while trying to load /groups/reviewers.json” error.

The group exists, yes. I’m able to see everyone in it by going to https://forum.snapcraft.io/groups/reviewers. You might have to be an admin to see it.

[Lin-Buo-Ren]

I would like to request pinning this topic in the store category, if that makes sense.

[Lin-Buo-Ren]

@noise
Apologizing for pinging, but I like to request again to move this topic to the store category and pin it there.

[Lin-Buo-Ren]

I would like to ask if mentioning each member individually using the mention feature of the forum would be considered unnecessary/troublesome/abusive. I’ve written some request templates and would like to make them as effective and non-offending as much.

[bartaz]

Reviewers are in the @reviewers forum group

@reviewers gets automatically changed into a link by discourse, but it is broken when viewed on https://docs.snapcraft.io/t/process-for-aliases-auto-connections-and-tracks/455 because it tries to link to docs.snapcraft.io/groups/reviewers.

I guess it could be changed to explicitly link to https://forum.snapcraft.io/groups/reviewers to make it work on docs site as well.