We’ve been using the Process for reviewing aliases, auto-connections and track requests 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.