Dear @reviewers, I would like to request the classic track for the nano snap. This track is meant to provide an alternative distribution of GNU nano that is in classic confinement while shipping the strictly confined one in the latest track.
This track was requested 5 days ago, so the initial waiting period will expire in 2 days, at that point we’ll tally existing votes and either make a decision or extend the voting period.
For context, this was suggested by Popey here, where he himself notes it might be a misuse of tracks. The version of the software being shipped in latest and classic is generally the same, which is not what tracks were envisioned for.
The only remotely similar case I could find is hugo, which has an extended track with mostly the same version of the software, but with an additional feature (libSass). One could argue that the classic version of nano has the additional “can modify files anywhere” feature, and take hugo as positive precedent for this request.
However, text editors are typically useful when they’re classic, and since classic was already granted for nano, I’m not sure I see much point on having the non-classic version available as well, as the usability will be much reduced (about the only use case I see is install-ability on Ubuntu Core systems).
I’ve presented arguments either way to aid other reviewers; my particular vote is -1 out of being strict on track semantics and purpose, but I recognize I’m not offering any good alternatives . Let’s see what the voting period brings.
I’d say that this is actually an important use case as snaps are the only packages you can run on IoT systems running Ubuntu Core and things like nano are very useful for developers there. I also think that while this might not be what tracks were intended to be used for, it’s currently the best option for having snaps that operate in both strict and classic modes - to me it’s worse to not have a strictly confined version of an app than it is to have this different usage of tracks.
Waiting period elapsed on this track request, and we don’t have enough votes; @reviewers, could you please have a look at this request and cast your vote/rationale?
This is a bit of a corner case. I’m not against the track in principle. I’m slightly worried about the name though, “classic” is a very overloaded word as we know. Indeed some editors might have versions called “classic” that are not our sense of classic here. Would “classic-confined” be too long/annoying?
The comment extension period has elapsed again with not enough votes (current tally is +1/-1). However, since this is being discussed as a general pattern in Track request(classic) for the tree snap, I think it’d be prudent to wait for the outcome of that before making a decision here. Other reviewers are welcome to enter votes/rationale to be considered, but the other discussion seems to have all the right people involved.
Sorry for the delay. We did discuss this and would like to propose classicmode as the track name, to avoid conceptually conflicting with other meanings for classic.
If this is OK with you, I can create this track.
(For reference, most of the Snap Store reviewers and one architect were present in the discussion so the votes were cast in person).