Simplified track request process for snaps with predictable cadence

store
1

Hello,

We’ve been using the Process for aliases, auto-connections and tracks process for a while, and we have run into the following situation:

Unlike aliases and auto-connections, which can be expressed once in a snap’s store-side records and then just “happen”, tracks need to be requested individually each time. Recently we’ve had requests from a few snaps which already had tracks (Go, Docker, Kubernetes, Openstack), and one from a snap which is using tracks and will have a predictable release cadence (JetBrains IDE). Asking the developers to file the request and then wait the full week for votes and outcome seems heavy-handed, particularly if their new request adheres to the parameters on which the first one was granted.

As seen in the Go track request, in principle they already know which are the upcoming releases, and so to save time, they could (and did) request the tracks in advance. My issue with that, as posted in that thread, is that if the version number is changed at the last minute (hey, we decided to call the next release 2.0 instead of 1.11) then the track will have been created in vain.

My proposal would be to allow reviewers to “fast-track” the track request if it applies to a snap for which there already are tracks, and for which the new track request is similar in nature and cadence to the first one. Track requests meeting these conditions can be processed as they come, saving everyone some time. In Go’s case, they don’t need to attempt to batch-request since they can be confident we’ll create the tracks quickly once they’re requested. For JetBrains, it’s a lower barrier for the next time they need a track.

I would love feedback from reviewers and architects about this idea.

Regards,

  • Daniel
2 Likes
2

I don’t typically process track requests, but this revised process seems reasonable: the initial request will see reviewers do all the necessary sanity checks and makes sure the publisher knows when and when not to use tracks, then for subsequent requests, the reviewer knows that the publisher knows how things work and can take a more pragmatic approach to the review. I do think that there should be an abbreviated review by at least one reviewer and that the reviewer should document in the request that the request was granted and why (eg, “granting request for track ‘1.11’ for their upcoming release”).

3

I’m in favor of a streamlined process for subsequent track requests. As long as it’s still following the agreed pattern from the first (approved) request there’s no reason to require the full process.

4

Should we amend the process to formalize this?

How about:

“A reviewer or architect can decide to grant a track request waiving the waiting period and without additional votes in the following case: if the request is for a snap which has already had tracks created, and for which the new request is consistent with previous ones for the same snap in semantics and cadence. The reviewer should reply in the request’s post explaining his rationale for waiving votes/wait period such as ‘granting request for track 1.11 since the snap has existing tracks and the new request conforms to the previous ones’”.

3 Likes