Please add "contact" field to the API

Bug #1666792 reported by Michael Vogt
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Snap Store Server
Fix Released
Wishlist
Unassigned

Bug Description

When we discussed how to contact the snap developers with Gustavo and the rest of the team we decided that we want have a "contact" field that in the store metadata instead of the current support-url field. The rational is that "support-url" sounds a lot like people can expect support. With "contact" it feels less formal. Note that for now it might be enough to just rename the field in the metadata form in the store. The snapd client use "support_url" if not "contact" is send in the metadata so this rename can come later.

Bret Barker (noise)
Changed in snapstore:
status: New → Confirmed
importance: Undecided → Wishlist
Bret Barker (noise)
Changed in snapstore:
assignee: nobody → Daniel Manrique (roadmr)
Revision history for this message
Daniel Manrique (roadmr) wrote :

Hello,

I have a few questions about this feature and how you'd like it to work.

First, ability to edit the support field was removed (albeit incompletely; it can still be added when first registering a snap's name) as part of this private bug: https://bugs.launchpad.net/snapstore/+bug/1672664. My first set of questions relates to how to restore the populating functonality: how do you envision this data being created/edited? via the web UI, or via a field in the snap.yaml? If the latter, what would be the name of the field? (presumably contact:). Is there already a snapcraft task to add this field (presumably from a corresponding one on the snapcraft.yaml file)? (A third option would be to allow both ways of populating the field, but this can be confusing).

You say "we want have a "contact" field that in the store metadata instead of the current support-url field." And "for now it might be enough to just rename the field in the metadata form in the store". A rename would be easy, but one thing that worries me is that other clients may be using support_url (see uappexplorer). If we simply rename the field they could break. But this bug AIUI is about very explicitly stopping calling that piece of data "support_url" so sending the same piece of data under both fields would send the wrong message. What we can do is publish the data currently in support_url under "contact:" and return a blank support_url so clients won't break but should see a behavior change. I'm not sure this is a great way of communicating the API change to unofficial clients, but it's one option to consider.

Finally, "The snapd client use "support_url" if not "contact" is send in the metadata". I'm not clear if this is already working (i.e. if I started sending "contact" field would snapd already pick it up?).

Thanks for the info!

Changed in snapstore:
status: Confirmed → Incomplete
Revision history for this message
Michael Vogt (mvo) wrote :

Hey Daniel. Thanks for your feedback.

To your first question: we discussed how metadata is handled during the recent development sprint. A short summary can be found here: https://forum.snapcraft.io/t/development-sprint-june-26th-2017/415/48. The basic idea is that the store keeps allowing editing meta-data like summary, translations, contact etc. snapcraft will upload this metadata to the store. The store will just accept new data and if there is existing data that is different the store reports an error and snapcraft reports this. Snapcraft grows a "update-metadata" command that allows forcing this update. So all metadata is available in snapcraft.yaml. The rational for keeping metadata in the store is that we don't want an upload of a snap just because e.g. there is a new summary or a description update.

Daniel Manrique (roadmr)
Changed in snapstore:
status: Incomplete → Fix Released
assignee: Daniel Manrique (roadmr) → nobody
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.