snapstore issues

2 minute read Published:

evolution of an informal protocol

When the snappy store first came to be it was initially populated by a small group of people working on the very first snaps. It was like a small family and everyone knew each other. The wild-west feeling remained for many months as you could pop in an internal or public IRC channel and ask one of the store developers or store administrators for a favour and get an instant response. Perhaps you need to register a reserved snap name? Maybe there’s a typo or your dummy snap needs to be removed. The store behaves oddly and you want to report an issue? Check, check check: all of those lived on IRC.

This is a natural process, people flocked together to a common medium where their friends and colleagues also hang out. We were all working on various parts of the same project. This has a natural tendency to be a internally transparent and externally opaque thing.

As a canonicaler I see the internal IRC channels and know many of the store developers. I know how to get my questions answered and my issues solved. I’m also aware that I am privileged and that this is not regular developers just don’t have that power.

As a project grows it is important to recognize such issues and address them.

Recently a fellow canonicaler poked one of the snappy store developers to delete a test snap that was uploaded earlier. During the short discussion that took place I suggested that such operations should not be done without a trace or due process. A dedicated project was recently opened on Launchpad, so that store issues could be reported and tracked in the open. It makes perfect sense to route such requests through a public, traceable medium such as the launchpad issue tracker. We should just do it.

You can now report store requests as bugs on the snapstore project.

comments powered by Disqus