Snapcrafters first virtual meeting minutes 03/06/2021

[rhys-davies]

Disclaimer: Minutes for snapcrafters meetings will not always be this long or unstructured, I just got over-excited.

Introductions

*Attendance: @Igor, @alan_g , @Lin-Buo-Ren, @joedborg , @kenvandine , @Wimpress , @tunix , @omer , @rhys-davies , @sergiusens , @galgalesh * Missing: Dustin, Dan, James (I’ll reach out to you each to update you and apologise for the poor timing)

Rhys - Developer Advocate, mostly here to support and help bootstrap initiative, does not meet the criteria to be a snapcrafter but here to help.

Sergio - Canonical, here to listen in, not snapcrafter necessarily. Yet.

Martin - Ubuntu MATE, Snapcrafter, interest in OBS and ffmpeg snaps so far.

Joe Borg - Canonical, since 2017, good at getting things upstream

Ken - Canonical, lots of desktop snaps, no snapcrafters snaps yet, maintains the GNOME extensions. Here to help out as best he can.

Alan - Canonical, Mir, maintains MIr snaps and graphics on Core. Here to keep up to date.

Buo-Ren Lin - Maintain and packages various snaps because he doesn’t want to build applications from source repeatedly, contributes to lots of snaps like youtube-dl.

Omer - Creating snaps for 4 years. Became involved with snaps full time six months ago. Maintaining Android studio and Sublime Text as well as others that are not part of Snapcrafters.

Alper - Maintains gradle and alacrity right now for himself. Developer. Likes that snaps are not PPAs. Needs more classic ability.

Merlijn - Maintains a lot in snapcrafters repo already but not under the store name yet. COntributed to snapcrafters docs and patches to desktop snaps. Mostly interested in desktop snaps, initially got into it to improve the Snapcrafters docs and tools, and in windows applications.

Igor - Snap advocate in Canonical, going to manage and bootstrap this initiative in the beginning and then take more snaps under his wing down the road

Snap ownership

We went through the list of snapcrafters’ snaps and identified snaps that people would like to become the snapcrafter for and snaps that should be moved officially under the snapcrafter name. Snapcrafters were invited to put their names next to more snaps to gain responsibility for them too. Official ownership can be seen in the snapcrafters repo. A more clear ownership list will be published once complete.

Processes

Igor asks about testing and the current procedure for reviewing PRs. Discussion ensued.

To start with, having everyone as a reviewer likely works to move things along, but if there are more technical nuances we can drill down. Igor will set up the necessary permissions on GitHub.

When there are more invasive changes and you regularly work with other snapcrafters you’ll learn to tag the right people.

How can we automate? Have better testing? Better communication? So it runs itself.

Ken - Desktop team has a lot of automation for triggering builds and tracking USN notices. So it would be great to have a lot of overlap with desktop snaps. Desktop snaps are migrating to GitHub under Ubuntu.

Alper - Functional testing? How do you do that for Desktop apps?

A test plan of manual tests in GitHub for people to use to test things themselves.

Buo-Ren Lin - Call for testing template used in his snaps: GitHub - brlin-tw/snapcrafters-template-plus: This is an unofficial fork of the Snapcrafters Template. Fork and edit me to start packaging a snap!

Rhys to share the start of a ‘snapcrafters processes’ doc to establish documentation for how snapcrafters operate

Alper - Maybe a word for the scope of current automation would be nice in that doc. Had a quick look at GNOME Calculator but couldn’t see anything.

Checkbox is a tool certification uses in Canonical could be worth proposing for snap testing.

Also used and worked while doing Ubuntu for Android was Xpresser, which screenshots a desktop and can be used to compare with specific desktop tests.

Omer - Do we have a place where Snapcrafters meet and chat together? We will vote on the social media tool for communication asynchronously

Omer - Communicating with upstream to ask them to take over their snaps. How do we do this? We need to define the process.

Merlijn - Track how and where we’ve communicated to the upstream.

Merlijn - Found people have used the review button in the snapstore rather than using the contact us link. Would be useful to have some interface in the snapstore for people submitting snap review to interact with the publishers. Seeing the reviews from the dashboard of the snaps. We will communicate this back to the Snap Store team, and see what they think/can do.

Martin - Divergence of desktop-helpers and snapcraft extensions. Would be good for us collectively to figure out what we do with this. In OBS there’s a hacky way of using the desktop extensions from snapcraft as a desktop helper because I know the hler doesn’t have what I need. There is a path to getting rid of desktop helpers entirely. There are some features of the helpers to bring over to the extensions.

Martin - “The “extensions” in Snapcraft were originally derived from the desktop-helpers. Today they are similar, but not the same.”

Sergio - The snapcraft team has a roadmap items for snapcraft games extension development in this cycle. Snapcraft's 21.10 Roadmap

Game extension discussion ensued of ideas to help and improve.

Snpacrafters team in GitHub and team in Discourse.

Merlijn - How do we find testers in the edge channel? These are all tentative ideas:

• Igor, new topic in discourse calling for testing with the nature of the update/change.
• Martin, discourse every time hurts us more with the slowing of momentum.
• Sergio agrees with Martin
• Merlijn has been burnt before by small changes breaking snaps and maintainers not knowing because of a lack of proper review
• Buo-Ren Lin: https://snapcraft.io/docs/channels#heading--branches
• We can use GitHub to announce testing
• We can create different levels of testing for snaps based on the severity of changes (minor and major versions, security updates)

If I missed anything or misrepresented anyone’s points please comment below and I’ll amend

[Lin-Buo-Ren]

@rhys-davies

Buo-Ren Lin - Maintain and packages various snaps because he likes snaps

doesn’t want to build applications from source repeatedly to be exact, snaps is just the solution convenient at the moment.

@rhys-davies

Snapctafters were invited to put their names next to more snaps to gain responsibility for them too.

typo

[James-Carroll]

@rhys-davies

Merlijn - Found people have used the review button in the snapstore rather than using the contact us link. Would be useful to have some interface in the snapstore for people submitting snap review to interact with the publishers.

I’d really agree with this comment. In some scenarios I’ve found bug reports about my own snaps in other “competitor” snaps reviews, the snap-store GUI does not show the contact link at all if I remember correctly.

Personally I’d add onto this, ODRS (Open Desktop Ratings Service) creates a substantial amount of problems. The fundamental issue is that it doesn’t distinguish between the sources of software (reviews of apps in PPA’s are merged with reviews in apps from other distributions!). One of my snaps has bug reports in the reviews that aren’t related to how the snap (or even snaps in general) works. One along the lines of “The snap does work but in order to make it work you have to place something into ~/local/foobar”, showing they’re using the apt version instead.

It also leads to some irony, Pinta is often a featured app, and while I’m grateful because it’s one of my own publications and I think the software itself is really neat and shows Snaps advantages really well. It ends up showing featured on snap-store with 2 stars because it recieves significant amount of 1 star reviews from the current state of the apt version. This doesn’t look good for any of the parties involved IMO.

Canonical used to host their own reviews service circa 2010 before transitioning to ODRS (though I may be mistaken). I think it’s worth Snapcraft doing the same to boost the experience around the reviews for publishers and users alike.

[Lin-Buo-Ren]

@James-Carroll

Canonical used to host their own reviews service circa 2010 before transitioning to ODRS (though I may be mistaken). I think it’s worth Snapcraft doing the same to boost the experience around the reviews for publishers and users alike.

Or we must somehow improve ODRS to adapt to the multi-ecosystems.

[tunix]

Quick notes:

• Google Meet’s performance with Firefox is awful. It was slow and lots of interruptions occurred. I had to install Chromium to make it work as expected.
• It was a pleasure meeting and seeing all of you in person.
• I wanted to adopt Discord but was afraid that I’d fail. But I’d love to be part of it. I tend to work on apps that I use daily.
• @kenvandine shared GNOME Calculator snap as an example but I missed why. Was it because it has proper testing or something else?
• I think @Lin-Buo-Ren’s template is very useful. I liked Checkbox but:
  • hmmm, no snap of checkbox?
  • Learning curve & initial work that needs to be done seems problematic (maybe we can fork from a bootstrap that makes it easier?)
  • What kind of tests can you write for a snap aside build tests?
  • (I wish we had something like Apple Script that allows us to puppeteer any apps)
• @rhys-davies can i take a look at the process doc? I think the final version should be a GH repo that we can send PR’s to update. Snapcrafters’ Constitution!
• We may need to define an acceptance criteria for creating new repos under snapcrafters name. At some point, there will be too many and there will be orphans.
• Something like a wiki would be nice for things like:
  • How to setup Github Actions?
  • How to do things on places other than Github? (Gitlab?)
  • Tips for newcomers (“enable compression for faster startup times” etc.)
  • How does branching & channels work? (I created a branch on GH and want to publish that branch to a channel on Snap Store) When to create forum thread?
• Though I felt what @Wimpress means by “discourse every time hurts” I think it’s sometimes a better way of finding new peers (not just for reviews) compared to GitHub. Also not all snaps have a link to their GH repo. Discovering GH repos may become cumbersome.
• I think something about automating security updates was discussed at some point. I think it should be the default for all snaps.

[Lin-Buo-Ren]

@tunix

We may need to define an acceptance criteria for creating new repos under snapcrafters name. At some point, there will be too many and there will be orphans.

As a never completed attempt, I had some view on such criteria: Snap Dump: An experiment of maintaining snaps, together, as an organization - snapcraft - snapcraft.io

[galgalesh]

@tunix

I think something about automating security updates was discussed at some point. I think it should be the default for all snaps.

I’d like the rebuild to edge to happen automatically when a security update happens. Then we should get a notification when the build is finished instead of when the update happens. Will make it a lot easier to manage security updates, in my opinion, since you only need to act once and don’t need to wait for a build to finish before you can continue.

[galgalesh]

Also, the actual reason I came here; since all core members now have write access to all repositories, we all got automatically subscribed to all repositories too. GitHub has a well hidden page where you can see all repos you’re subscribed to and an easy interface to change those subscriptions: https://github.com/watching

(I’m personally only subscribed to the repositories I maintain. When I’m needed, you can call me using @galgalesh or @snapcrafters/reviewers)