Process for aliases, auto-connections and tracks


#1

Definitions

  • Reviewers are in the @reviewers forum group
  • Architects are those responsible for the design of snapd.
  • Votes are in favor (+1), against (-1), abstain (+0)
  • Voting period is one week
  • Voting period extension is 3 days

Process

  1. Requester creates a forum post in the store category and makes case for change. To disambiguate snaps, the requester should either give the store URL for the snap or give the name and publisher of the snap. Voting period starts at time of request.
  2. Requester may not vote on his/her own snap.
  3. Reviewers and/or architects vote using the voting procedure (see below). Each vote should include a short rationale for the cast vote.
  4. If after voting period there are not enough votes based on voting procedure, a voting period extension should be requested by a reviewer/architect. The extension starts the day of the request for extension
  5. At the end of the voting period, a reviewer/architects tallies the results from the voting period (and extension), summarizes in the forum post and performs any necessary actions.

Voting procedure

  • The voting procedure is the same for granting and revoking auto-connections, auto-aliases and track requests.
  • If reviewers and up to at most one architect voted: simple majority with at least 2 votes in favor at end of voting period/extension: perform requested action.
  • If two or more votes in favor/against from architects: reviewers votes are not tallied. If have only in favor votes from architects at end of voting period/extension: perform requested action, otherwise architects discuss until no against votes and at least one vote in favor from architects. If clear direction from architects, an architect may request the vote be tallied early.

Executing ping within a snap
Track request for subiquity: artful
Track requests for dmd snap package
Track request: new 1.4 track for ldc2 snap package
Snapping CUPS Printing Stack: Avahi support, system users/groups
Request tracks for u1test-snap-with-tracks
Sanitisation of snaps' requested interfaces
Auto-connecting interfaces for easy-openvpn snap
Automatic alias for bluez snap (btmgmt command)
Track request for OpenStack projects
Track request for prometheus
Track request for OpenStack gnocchi and cinder snaps
Use of home and network plugs
Request aliases for torxakis
Classic confinement for ubports installer
Snapping CUPS Printing Stack: Avahi support, system users/groups
Kubernetes 1.9 snap tracks
Simplified track request process for snaps with predictable cadence
Docker snap tracks request
Get a list of user-defined aliases of a snap
Classic confinement for yarn
Documentation outline
Auto connecting removable media
[Help] Changing the snap name causes a failure in execution
Multi tracks for Apache Drill
New track "cali" for edgexfoundry-core snap
Requesting tracks for 'node' snap: 6, 8, 10
The snapd roadmap
Publish snap with classic confinement
How to load Iptable rules on startup, what plugs are needed?
Request automatic alias for ubuntu-make
How to get serial number of hard-disk in a snap packed application with strict confinement?
Please auto-connect camera interface for flock-chat (Was: Need classic confinement to get camera access and file download)
Request for new "extended" track for "hugo" snap
Tracks request for microk8s snap
2.3 track for Juju request
Confinement help with snapping indicator-sensors
Automatic aliases for ldc2 snap
Automatic aliases for ldc2 snap
Store assertions alias for vscode
Auto-connecting interfaces for bcc
Which snaps should be supported by canonical
#2

OTOH, I suggest that snappy architects and store reviewers get a vote such that:

  • if >= 2 +1s, grant after 1 week of initial request (to give architects, et al a chance to read)
  • if >= 2 +1s from architects, grant immediately regardless of number of reviewers’ -1s
  • if architects disagree, do nothing until they agree
  • reviewer may not vote on his/her own snap. An architect may vote on his/her own snap.

This should allow things to move ahead without needless red tape. If architects disagree at a later time, that is cause for re-discussion with the same voting procedure as above for revocation.


#3

After giving some thought on corner cases last night, here is a more formalized proposal:

  • reviewers are https://launchpad.net/~myapps-reviewers
  • snappy architects are Mark, Gustavo, etc
  • votes are in favor (+1), against (-1), abstain (+0)
  • voting period is one week
  • voting period extension is 3 days

Process:

  • a requester creates a forum post with the ‘store’ tag and makes case for change. To disambiguate snaps, the requester should either give the store URL for the snap or give the name and publisher of the snap. Voting period starts at time of request
  • a requester (reviewer or architect) may not vote on his/her own snap
  • reviewers and/or architects vote using the voting procedure (see below)
  • if after voting period there are not enough votes based on voting procedure, a voting period extension should be requested by a reviewer/architect. The extension starts the day of the request for extension
  • at the end of the voting period, a reviewer/architects tallies the results from the voting period (and extension), summarizes in the forum post and performs any necessary actions

Voting procedure:

  • the voting procedure is the same for granting and revoking auto-connections and auto-aliases
  • if reviewers and up to at most one architect voted: simple majority with at least 2 votes in favor at end of voting period/extension: perform requested action
  • if two or more votes in favor/against from architects: reviewers votes are not tallied. If have only in favor votes from architects at end of voting period/extension: perform requested action, otherwise architects discuss until no against votes and at least one vote in favor from architects. If clear direction from architects (eg, no abstain votes), an architect may request the vote be tallied early.

#4

Rationale and proposed process sounds like a great start, thanks for putting it in place Jamie.

As a minor addition, might be good to request the inclusion of a short rationale to back any positive or negative votes, so that others can comprehend the reason and correlate or not.

Then, as a trivial detail, store is actually a category in the forum rather than a tag.


#5

Thanks @niemeyer

Based on that, here are the approved procedures:

Alias and Auto-Connection request and approval process

Definitions

  • reviewers are https://launchpad.net/~myapps-reviewers
  • snappy architects are Mark, Gustavo, etc
  • votes are in favor (+1), against (-1), abstain (+0)
  • voting period is one week
  • voting period extension is 3 days

Process

  • a requester creates a forum post with the ‘store’ category and makes case for change. To disambiguate snaps, the requester should either give the store URL for the snap or give the name and publisher of the snap. Voting period starts at time of request
  • a requester (reviewer or architect) may not vote on his/her own snap
  • reviewers and/or architects vote using the voting procedure (see below). Each vote should include a short rationale for the cast vote
  • if after voting period there are not enough votes based on voting procedure, a voting period extension should be requested by a reviewer/architect. The extension starts the day of the request for extension
  • at the end of the voting period, a reviewer/architects tallies the results from the voting period (and extension), summarizes in the forum post and performs any necessary actions

Voting procedure

  • the voting procedure is the same for granting and revoking auto-connections and auto-aliases
  • if reviewers and up to at most one architect voted: simple majority with at least 2 votes in favor at end of voting period/extension: perform requested action
  • if two or more votes in favor/against from architects: reviewers votes are not tallied. If have only in favor votes from architects at end of voting period/extension: perform requested action, otherwise architects discuss until no against votes and at least one vote in favor from architects. If clear direction from architects (eg, no abstain votes), an architect may request the vote be tallied early.

Set up auto-alias for gofmt in go snap
Store assertions alias for vscode
Automatic aliases for ldc2 snap
How to get several direct-access wrappers from one snap?
Auto-connecting interfaces for bcc
#6

@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.


#7

I’ve done this just now.


#8

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!


#9

FYI, I did this yesterday.


#10

@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?


#11

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?


#12

@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.


Requesting automatic alias for dotnet
#13

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>

#15

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:


#16

#17

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


#18

The current ‘myapps-reviewers’ from LP are:

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


#19

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.


#20

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.