Process for aliases, auto-connections and tracks

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

1 Like

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.

1 Like

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.

2 Likes

Dear @reviewers, I would like to request the 18 and 20 tracks for the nitrogen-gadget and nitrogen-kernel snaps. so that I can maintain both versions, especially since gadget 18 & 20 versions really aren’t compatible.
Thanks in advance.

1 Like

for this you should open a fresh topic in

(as explained above) … instead of comenting on the process documentation :wink:

2 Likes

Thanks, will do. To be honest this whole process is confusing (relying on forum). Wouldn’t it be better to have a request button in the dev account directly without going through the forum?

1 Like

Usually there are questions from the reviewers and discussions around granting any of the above. While a forum is indeed not the greatest way of communicating, it is a way to have the discussion transparently in public and centralized in one place …

an alternative would be a public mailing list or something similar.

having per-snap discussions (i.e. in a github issues style) would make the work of the reviewers much harder and it would make it much trickier to do forensics years later of “why was this permission granted to that snap, by that guy thats not in the reviewers team anymore” if i.e. a change to/extension of the permissions is requested.

3 Likes

Hi all,

I recognize this topic is over 2 years old, but it makes sense to keep related information together.

Similar to the the approved Simplified track request process, I’d like to propose a change to the process for auto-connections to encourage more active participation in the review process by @reviewers, and to the extent possible without compromising the integrity of the process, accelerate the granting of declarations under certain circumstances, ie: fast-tracking approval.

Rationale:

As jdstrand has stated previously, we have a 7 day voting period at least partly because:

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

In practice however, rarely are architects or more than 2 reviewers (beyond those rostered on for reviews) assessing and voting on requests during the voting period. Therefore, we rarely benefit from the opportunity provided by a 7 day voting period.

Conversely, some requests sit stalled awaiting a vote that comes right at the end of the 7 day period, and are then actioned almost immediately. The intention with this change in process is to encourage more reviewers to attend to the forum more regularly (see the propsoal below), with the knowledge that their input will be immediately impactful. In doing so, we will improve the publisher experience by processing requests sooner, and the quality of reviews by increasing the number of reviewers involved in (some) requests.

Proposal (the details are welcome to be tweaked)

  1. The standard review period remains 7 days, with the following exception:
  2. auto-connection requests may be completed sooner, under the following conditions:
    1. The request be well-understood and deemed likely to be supported by at least 3 reviewers: (ie: three +1s)
    2. The request is consistent with similar, already approved requests
    3. If any reviewers do not support the request (ie: vote -1) the request is not eligible for fast-track processing.
  3. When a reviewer identifies a request they believe satisfies 2.1 and 2.2, they should mention other @reviewers to get more votes citing the request as a candidate for fast-tracking.
  4. If three +1 votes are received for a post identified as such, the reviewer may grant the declarations, waiving the remainder of the voting period.
  5. Reviewers are encouraged to request that the entire voting period apply, should they require more time to assess a request.

Feedback from @reviewers, architects (@pedronis) and @advocacy welcomed.

2 Likes

One thing that might also help is for requesters that have already asked for similar functionality in the past to mention past requests, as these could potentially be considered a “+1” in its own right.

1 Like

The change seems reasonable to me given how the flow usually works in practice. I do wonder though if we should have any more explicit policy difference between privileged and super-privileged interfaces.

1 Like

This is a bit unclear to me as the requests would likely be in the context of different snaps, so they could score differently with respect to the policy criteria.

1 Like

That would be in line with he proposed 2.2. clause, and if the requester is well known, that would also help - a first-time requester may also need publisher vetting and similar.

1 Like

Yes, good point.

My initial reaction was that we could scope this to non- super-privileged interfaces only, however that would probably defeat some of the more likely use-cases for fast track which would be personal-files and system-files (especially path updates/additions). I think we would want these to be eligible for fast track (when the publisher is already vetted). If vetting is required, fast track is not possible.

Perhaps we add:

X. Super privileged interface auto-connections are not typically eligible for fast-track as publisher vetting is required and extra scrutiny is required when considering the use of super-privileged interface plugs. Only if the publisher is already vetted and the criteria defined in 2.1-2.3 remain satisfied, then super-privileged interface auto-connection may be considered for fast-track.

?

1 Like

personal-files and system-files are special among superprivileged interfaces in that they are either straightforward (assuming the packager is connected to upstream) if they refer to files that are clearly owned by the snapped application/service, and needing careful consideration otherwise.

1 Like

Agreed. Here is a revised text which calls out super privileged interfaces specifically:

  1. The standard review period remains 7 days, with the following exception:

  2. auto-connection requests may be completed sooner, under the following conditions:

    2.1. The request be well-understood and deemed likely to be supported by at least 3 reviewers: (ie: three +1s)

    2.2. The request is consistent with similar, already approved requests

    2.3. If any reviewers do not support the request (ie: vote -1) the request is not eligible for fast-track processing.

  3. Super-privileged interface auto-connections are not to be considered for fast-track unless the following conditions are met:

    3.1. The request pertains either system-files or personal-files; and

    3.2. The request pertains to files clearly owned by the snapped application/service; and

    3.3. The publisher has been vetted appropriately.

  4. When a reviewer identifies a request they believe satisfies 2 and 3 above, they should mention other @reviewers to get more votes citing the request as a candidate for fast-tracking.

  5. If three +1 votes are received for a post identified as such, the reviewer may grant the declarations, waiving the remainder of the voting period.

  6. Reviewers are encouraged to request that the entire voting period apply, should they require more time to assess a request.

1 Like

This revision looks reasonable.

2 Likes