Supporting and issue reporting for snaps

I absolutely love everything I read here. There can be a certain lack of love in the larger Linux world for Ubuntu but this sort of concrete vision should dispel a lot of common complaints.

Two things that come to mind as I read this:

  1. Fragmented communication channels currently exist across the whole of the Canonical/Ubuntu landscape. Things are starting to jell on this Discourse but the Snapcraft one is, for example, its own silo. I’d personally love to see all of those consolidated.
  2. Snaps are great in many ways but have many detractors. I would love to see more careful (and automated) curation of submissions before publishing. There is also a huge, glaring issue in that it is almost impossible for an average user to figure out where and how to submit a bug report for a Snap. To me, that is a major problem that makes it hard to advocate for Snaps.

Just my two ¢ but keep up the good work! I’m looking forward to hearing more like this from you!!

10 Likes

Would this not be the right place to direct users to?

Do you call your street and infrastructure department when your car does not start ?

Filing a bug against snapd when having issues with an application using this package format is in 99% of cases the wrong thing to do…

Snap packages usually define a contact: field (there is also one for bugs but that is relatively new and not many packagers use it yet)… The typical way to find a bug url (or at least a mail address of someone who can tell you where to file bugs) is:

snap info <package name> | grep contact

That usually returns an url or mail address of someone you can contact for issues…

2 Likes

@ogra my apologies if this was not the correct suggestion.

It was based on what I thought I understood from here:

To keep my analogy, yes, if there is a sinkhole in front of your driveway on the street, you do indeed call the street and infrastructure authority to fix it… If there are issues with snapd itself you should indeed report them at the mentioned place :wink:

2 Likes

I do not want to hijack this very valuable thread, so if we want to continue this discussion about reporting bugs in Snaps, we should do it elsewhere. Here might be good.

That said, I do agree reporting bugs against snapd is a bad idea. When there’s a problem in the Firefox Snap, nearly 100% of the time, it has nothing to do with snapd. To make this make more sense, it would be like filing all bugs against Ubuntu’s Debian packages against apt or dpkg. If that still doesn’t name sense, think about being a snapd developer. You’re trying to figure out bugs to fix but to find them you have to go through the list of all Snaps and exclude them from your searches. That’s not just annoying, it’s untenable!

However, I think that the engineering solution to this problem is adapting apport to Snaps. That is for Ubuntu, at least. Since Snaps are a universal solution, maybe having some less distro-specific mechanism built into snapd would be better.

2 Likes

Believe me, I did not intend to start a discussion that would lead in this direction.

My post was based on ignorance not any wilful desire to upset the apple cart.

Both you and @ogra have educated me on this matter and I value the lesson.

Well, now we’ve been moved out of the original discussion, so I guess we can speak freely.

I, for one, didn’t leave those comments to be critical of you, but meant to instruct. That same sort of thinking is valuable for all sorts of things. Like, for example: if there’s a bug in a desktop application, you don’t file it against the ubuntu-desktop package! Anyways, it seems like you got it.

Still, though, I think that your comments do actually illustrate my original concern. We still need a solution here.

1 Like

The problem is that there is no easy solution to it…

Whatever tool you would provide would need to be able to talk to all imaginable bug trackers, we can’t force snap packagers to use launchpad…

Snapcraft has recently grown an issues: field that you can put a bug tracker url in and up to now many snaps use the contact: field to provide a bug url, this is surely already going in the right direction but we won’t have something like apport for it…

Perhaps the snap command could grow a snap <snap name> report-bug sub command that opens a browser with the url from the issues: field, but that would still require that the packager actually makes use of this field in the first place.

1 Like

On that linked post I sent, I dealt with this one particular issue: we make such metadata a requirement for Snaps to be submitted to the store. That seems incredibly easy and obvious to me.

The comment that I think is perhaps the most relevant is this:

As an average user how about something like this:

The field could say something like to report a snap bug click here.

Then a dialog would open with required fields such as name of the snap, version if applicable, Ubuntu or flavour version, brief description of the issue.

Clicking upload or report would then automatically send it to the snap maintainer/developer.

Or perhaps send the bug report to the relevant section on UD to get as many eyes on it as possible?

Is this even feasible?

Well, you cant really force companies to provide a bugtracker for their proprietary software, don’t forget that snaps are not only for opensource software … I’d happily have a photoshop or autocad snap in the store if that brings more people to linux in the end and neither of the two would (be able to ?) provide a bugtracker URL …

1 Like

I hadn’t really considered that, but that’s a darn good point. Another example of Snap strength (easy distribution for software of all kinds) also being a point of weakness.

You have to admit, though, this is a really troubling problem from an average user perspective. I’d say this is especially true for those users that actually are familiar with using apport. Maybe the right solution for Ubuntu is to make apport work with Snaps and read the metadata and act accordingly. If there isn’t any relevant information, it can report that back to the user and at least place the blame in the right place: that the packager/developer does not provide that information. Other distros can create their own machinery for this purpose as they see fit, but at least we can fix it for our users.

In case it’s not obvious, all of this is inspired not by a distaste for Snaps, but a desire to promote them more. However, it’s really hard to convince users when they are faced with unfriendliness. Furthermore, many users lack the technical background to understand the nuance we’re discussing here. The end result: they blame the packaging (which is actually rather unquestionably great from a user perspective) for their problems. It’s kind of like the analogy you gave before…

Contentious counter point

Average users don’t file bugs, and when they do, they’re worse than useless.

A random example from today: Bug #2098100 “System Fails to Boot” : Bugs : Ubuntu
Had a launchpad account for 7 years, and this is their first bug report.
I don’t think we should make it too easy for “average” people to talk to developers. :smiley:

I mean everyone has to start somewhere. You don’t stop building schools because the students don’t have the best study habits or learning styles.