Currently we show one featured snap in GNOME Software (i.e. the banner at the top of the app) and suggest other snaps as “Editor’s Picks”. This is done by using the featured section in the snap store and using the first item as the banner and the remaining items as Editor’s Picks.
It would be desirable to show more than one featured snap with the banners scrolling between them. Since the featured snap is not explicitly set we can show snaps without banners configured, which doesn’t look great.
I’d like to propose we add a snap category that contains the snaps that should be featured to make this more explicit and allow multiple featured snaps.
In addition, we ‘d also like to see snap pages (eg: snapcraft.io/mailspring) linked together into categories and made more browsable, so it’s easier for folks to discover Mailspring while they’re looking for another mail client, for example.
We could also continue to use ordering to separate the Featured from Editor’s Picks. If, say we were going to scroll through 3 apps in the banner, we could assume the first 3 had banner assets and were appropriate for being in the banner. This would require minimal changes all round and could be the best short term solution. A better mid-term solution would be to have a separate section as you propose for these kinds of snaps.
I believe the behaviour between Ubuntu versions is already different, for example 16.04 and 17.10 have different views and categories, could we avoid the SRU process by saying this is an 18.04 change? Having said that, I don’t think a minor change like this would be controversial.
snapd just returns a list of software, Gnome Software interprets that in any way it likes. Why would Gnome Software need to behave differently with different snapd versions?
Sections are the way to go in the future, I am trying to explore what we can do in the short term with the minimum or changes.
I was listing the general costs here as there’s been a bit of a trend to to collect workarounds in the client and that’s getting expensive. It’s fine to spend these costs when necessary - I just want to be sure we’re doing an appropriate trade of work between the teams. We’re hit all these costs on various features in the past.
The costs in this particular case would be:
As long as this can be achieved purely using sections, no changes in snapd-glib initially. We will later need to update snapd-glib and gnome-software when we move to explicit feature snap metadata (i.e. this feature will have to be worked on two times).
If this feature is only about populating the number of featured snaps, then the upstream changes will be confined to the snap plugin code. If changes are outside the plugin this requires more review as upstreaming code is generally more expensive than changing projects we have full control of.
We could limit this to an 18.04 change, but the snap promotion work is most valuable in the LTS releases, so this would be two SRUs (once for hack, and again for section solution).
If the “featured” section is sufficiently loosely defined that we can have different clients interpret in in different ways then we don’t need to check the version of snapd. However this means that different desktops are unlikely to support promoted snaps as it’s not clear how to do this and it’s not exposed in any APIs.
