[abandoned] Track request(classic) for the tree snap

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!

1 Like

Bumping topicā€¦

Just try to tree /snap/pre-commit/current and it reminds me of this topic :slight_smile:

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).

  • Daniel
1 Like

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

1 Like

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).

  • Daniel
1 Like

+1 to the track request, I agree, I see no problem with this track use-case. Dare I say they should be self-serviced.

1 Like

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.

1 Like

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)
1 Like

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).

  • Daniel

Iā€™m fine with that. Thanks!

Hey!

Track is ready to be used (classicmode) - similar to what we did with nano.

  • Daniel
1 Like

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.

@pedronis Can I get any input from you?

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.