Dear @reviewers, I would like to request the classic track for the tree snap. This track is meant to provide an alternative distribution of the tree command that is in classic confinement while shipping the strictly confined ones in the latest track simultaneously.
The classic confinement usage is being discussed in [revoked] Classic confinement request for the tree snap .
Thanks in advance!
Bumping topic…
Just try to tree /snap/pre-commit/current and it reminds me of this topic 
Hello,
Sorry! At this point, we’re in “extension” territory since we didn’t get enough votes in the first 7 days of voting. @reviewers, could you please have a look and cast votes/opinions on this request? We’ll check for any votes or results on April 29th.
This is similar to New track(classic) request for the nano snap (which is also awaiting resolution). The version of the software being shipped in latest and classic is generally the same, which is not what tracks were envisioned for.
As for nano, classic has to be granted for the snap anyway (i.e. granting the track doesn’t negate the need to approve classic confinement for the snap which would be used on some revisions and not others) - 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, IMO much less of an issue with tree than it is with nano).
Consistent with my thoughts on nano, my particular vote is -1 out of being strict on track semantics and purpose (though I’m hoping other reviewers can chime in and we can suggest a good alternative for this use case).
I am a reviewer but don’t usually vote on track requests, however, I was part of the other thread and feel this is an appropriate use of a track. +1
Hello - This request still doesn’t have the required number of + votes (current tally is +1/-1). @reviewers, could I get a few more eyes/votes on this request?
Extending the vote/comment period for another 3 days (yes, 3 days, I’ve been doing it wrong!) - we’ll check back on May 2nd).
+1 to the track request, I agree, I see no problem with this track use-case. Dare I say they should be self-serviced.
I appreciate all the input on this new idea for usage of tracks, but given that it is a departure from original design and guidelines I’d like to discuss with some others before we open the gates for this as a general pattern.
@pedronis @niemeyer @mvo - could use your input on this usage of tracks for differentiating between classic or strictly confined versions.
So a “classic” track is not a version of the underlying software but it is a version/variant of the snap, in general this proposal also shows that once there’s a way to carve a namespace it will be used, we have track and branches with very defined purposes, but people will try to color a bit out of the margins, we need to be aware here. I have the following considerations anyway:
classic-confined name1.01.0-classic-confined (this way, not the other around)As noted in the classic track request for Nano:
Hello,
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).
I’m fine with that. Thanks!
Hey!
Track is ready to be used (classicmode) - similar to what we did with nano.
It’s been a very long while, however, I have now started publishing classic confinement snaps using the classicmode track. It’s now stuck in the manual review queue, though.
To help the @reviewers revalidate the usage, here’s the packaging recipe for these snaps:
https://code.launchpad.net/~snap-dump/tree-snap/+git/tree-snap/+ref/classic
It is based on the master branch which builds and publishes the snap in strict confinement, with only two additional patches to switch to the classic confinement:
The requirement for classic is pretty clear, as it requires access to arbitrary areas of the filesystem to provide its expected functionality. However, I don’t clearly see in which supported category tree fits.
@alexmurray thoughts ?
Just a friendly reminder that the usage of the classic confinement is already vetted at [abandoned] Track request(classic) for the tree snap - #11 by roadmr .
UPDATE: See
Unfortunately I can’t see any clear evidence that @roadmr approved the use of classic for this use-case. And to my understanding there is no supported category for classic confinement that tree fits within. As such I do not think it is appropriate to grant the use of classic confinement - unfortunately the snap confinement model means that some snaps will not be able to work in all use-cases.
I would like to argue that the track name(and the entire request topic) literally suggested the usage of classic confinement.
I agree, however, I wish this was communicated in advance as I already invested my time into the task assuming that the blockage is already cleared.
To echo @alexmurray’s point, the vote I cast back in 2019 was specifically for the track, not for classic confinement. You said in the OP it was being considered in another thread, so why would I cast a vote on that here?
Thanks for pointing that out! I have misinterpreted that this track request has superseded the classic confinement request thread I previously made:
As the usage of classic confinement clearly does not fit within the supported categories of classic confinement snaps I’ll stop pursuing it and will simply publish devmode snaps to the users, however, we should really revise the track request process to require vetted classic confinement before the application of the classicmode track to avoid giving mixed signals to the applicant.