Official snap for review-tools

snap-requests
1

There is review-tools. I could not found a reference to the snap bundling source code. Would it be possible to support this officially?

2

You’re looking for the source code for the review-tools snap? That’s here.

1 Like
3

Ah, I see: Jamie Strandboge is the author of both, the code on launchpad and the snap. Thx.

4

I think this is one of the many symptoms of an issue that comes up frequently; that it’s very hard to connect snap packages to the snap sources, bugtrackers, and the application sources.

It would be really useful if there were “bugtracker”, “packaging info” and “app source code” metadata fields. The “contact” url is the one I point to the GitHub bugtracker and I hope people can infer the source code of the packaging is in the same repository, but this is not very intuitive.

This thread is the “trust” variant of the issue but this has also come up in the context of reproducible builds and of people wanting to fix bugs in the packaging.

3 Likes
5

Agreed. Would be great if the backend store had fields for these. We could then nudge developers to fill them in via the web frontend.

@noise is there any chance we can get some additional metadata added to the backend, such that users can more easily derive the origin and bug trackers for snaps published in the store?

2 Likes
6

We have some open design work in this area to expand that set of fields (currently “Developer Website” and “Contact”) and/or expose some of the information gathered in the build manifest, but are also wary of having field overload.

7

Some of my thoughts on this:

  • Exposing the build manifest itself is really useful. Many people do not know that this even exists and it contains a lot of info to improve trust and help contributers. Exposing individual fields might also be useful but I think most people interested in this info won’t mind reading through the manifest.
    • If the build log would also contain a url to the repository used to build the snap, this would remove the need for a “packaging info/source” field.
  • A link to the source code for FLOSS apps is really important in my opinion. Many apps are open source; making it easy to find that source banks on that.
  • The biggest issue with the “Contact” link is how it is presented to the user on the Snap Store. Take the snap for TrackMania Nations Forever, for example. It is not clear that “Contact Snapcrafters”, will take you to the issue tracker of the snap. I’m not sure how the wording could improve to support both email addresses and bugtrackers. The only thing I can think of is super long: “Do you have questions or did you find an issue in this application? Contact Snapcrafters.”
2 Likes
8

I’m a newby to snapcraft. To me the proposal makes a lot of sense.

Take the snap for TrackMania Nations Forever, for example.

Nice “burndown cognitive load” game BTW :stuck_out_tongue_winking_eye:

1 Like
9

I can’t like this enough, but I’ll try.

+1000

I would love for the build manifest/log to be more easily discoverable. Eg, one idea is on https://snapcraft.io/<snap>, there is a drop down next to the install button. Something in there could link out to the build manifest. Probably better is a link under ‘Details for SnapName’ on the right that links out to a page that shows the source URLs, snapcraft.yaml, manifest.yaml, build log, etc. This could be on by default for anything built on build.snapcraft.io or launchpad.net that has an open source license (with opt in/out as needed). Someone would have to design this of course. Best practice would dictate to only install snaps from publishers you trust, and this transparency would go a very long way in helping users decide who to trust (cc @noise).

5 Likes