There have been several discussions now about where to report Snap bugs, but we have several Desktop Team-maintained snaps that want a bug report on Launchpad.
Unfortunately, when looking at the place the actual development is taking place, that’s where the actual discussions are happening. Seeing as how this is the Ubuntu community, we don’t want to obfuscate such discussions.
In order to keep confusion at a minimum, and to keep discussions in the open and not obfuscated, I propose that the Desktop Team ceases using Github for issue discussions and keeps them on Launchpad in the reported bugs. Either that, or change the snaps to request reports on Github issues.
Is there any reason to make this exclusive to the Desktop Team? Shouldn’t this be something that applies to all Snaps maintained within our own community?
I’d also suggest for any Snaps we’re shipping or officially recommending (e.g. the installer recommending third party apps), flavors (remembering again here that vanilla is a flavor, too) should be pushing hard for the maintainers of those Snaps to create similar cohesion.
I maintain Freeshow, and we want all issues, including the snap issues, on Github. To split that would be fragmenting. It’s an upstream project, but is unique in that it’s seeded in Ubuntu Studio, but not exclusively maintained as part of the Ubuntu community.
I’m actually suggesting ensuring that all of our community Snaps use one unified location, so your example is an example of what I’m suggesting. That seemed to be what you were suggesting to begin with: to pick one and only one place to report and manage bugs and do development.
If I think I’m reading you correctly, you want each snap to pick one spot for their bugs. I agree with this. The reason I was singling out the Desktop Team is because of what I found out:
They want bugs reported one way, but…
Internally, their discussions and reports are happening elsewhere, or not necessarily where the bug was reported.
Which, of course, leads to poor collaboration and poor community interaction, and especially poor bug triage.
Right, and we are in agreement. I was saying we should extend this through all the Snaps that we are developing.
I should be clear that when I say “we” I mean flavors. So I am referring to those Snaps that flavors are maintaining, shipping, or officially endorsing.
Great discussion to have. I was reminded recently we have ubuntu-desktop-provision bugs in both Launchpad and GitHub.
I agree Launchpad is the preferred place for bugs because it allows people to do Launchpad things like report a bug against the wrong package at first, and for bugs to have tasks spanning multiple packages.
But regardless of the bug tracking location, I’ve wondered why I can’t do these things:
I generally agree with this, but I personally think it makes little sense to require it for Snaps. I would imagine there are very few Snaps that are hosted on Launchpad. Since Snaps are universal, we don’t need to approach the technology in a Ubuntu-specific way. Not like Launchpad is Ubuntu specific, but it tends to be. Using @eeickmeyer 's example above, if you filed a bug on Freeshow in Launchpad it would likely get ignored or be an irritating second place to have to come and duplicate effort. Better to keep it open. So again, using that example, GitHub is fine.
I think the best that can do is read the metadata from the Snap and direct the user there. You don’t want the Snap machinery to be distro-specific.
On the other hand, within Ubuntu and outside of snapd itself, I think it would be wise to modify ubuntu-bug to read Snap metadata, collect diagnostic information, and attempt to file a bug. We should be able to do the first two and at least open a URI from the “contact” field. Search elsewhere in metadata if no “contact,” and report failures to the user, telling them where the diagnostic information is. Finishing it all off will require building in support for bug tracker APIs, so that will be a little slow going at first.
One thing to point out: Snaps can be used by proprietary software. There are several examples in the stores. JetBrains’ contact is to their docs. Spotify has a community page, but I’m not sure that’s exactly a bug tracker. VS Code is “Twitter” whatever that is. So there definitely are things for which our best intentions aren’t going to work for.
The context of this discussion from the beginning was snaps maintained by the Desktop team only. So I’m only suggesting those snaps have their bugs tracked in Launchpad. Or even a subset of those - any Desktop Team projects with bugs already tracked in Launchpad should have their upstream bugs merged into Launchpad. It can happen slowly like preventing new GitHub issues being opened.
And my suggestions for snap sub-commands are in no way distro-specific. snap report-bug for example would just xdg-open whatever URL the author put in the metadata.
This problem leads to an absurd situation for the installation, in case of crash a window appears inviting me to type ‘ubuntu-bug ubuntu-desktop-bootsrap’ and then I see a message inviting to visit forum.snapcraft because ubuntu-bug does nothing.
Note: also ‘report the issue’ just opens an empty bug on launchpad.
This was meant to be about Ubuntu Desktop Team snaps only.