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.
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).
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).
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:
we are trying to get strict snaps as much as possible, not classic ones, so we should have “classic” tracks, not “strict” ones if we adopt this. We absolutely shouldn’t do this both ways.
as I said elsewhere there might be software where “classic” is an upstream designation of an actual version stream so I do really prefer if we do this the more cumbersome classic-confined name
we ideally shouldn’t really do this for anything that expects actual version tracks but if that happens we need to be ready to live with things like this:
1.0
1.0-classic-confined (this way, not the other around)
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).
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:
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.
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.
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.