Pulse 13 - Ubuntu Desktop engineering update

Hello all,

Tim again with your fortnightly desktop update. Let’s jump straight in.

Jira totals

  • Tickets: 478 (up 16)
  • Untriaged: 186 (up 22)
  • Open: 292 (down 6)

This pulse totals

  • Triaged: 106
  • Resolved: 76 (down -3)
  • Carried over from pulse 12: 30

Because we want insights into where we’re spending resources, we need to make sure our ticket metadata is complete. In time, this will support capacity planning and give excellent insights into where we’re spending our time (ie maintenance, packaging, building new features, etc). All this to say, expect fluctuations in the metrics I share because our processes are evolving.

Onto plumbing

I’m happy to announce that polkitd 122 landed in mantic. You might wonder why I’m leading with this update, until you read that the previous version, 105, was released in 2012! The blocker for a straightforward upgrade was polkit moved to javascript-based rules, and to support that, it introduced a dependency on Duktape. That is now sorted and all rules have been rewritten in javascript. You can read more in this in Jan 2020 post.

@jpnurmi continues doing awesome things in flutter. This pulse he has brought us a step closer to automated releases for our flutter repositories. This is enabled by using conventional commits in our repositories to enable auto generating release PRs for eventual publishing to https://pub.dev/publishers/ubuntu.com/packages (see https://github.com/googleapis/release-please and https://www.conventionalcommits.org to learn more).

App store

I’ve mentioned previously that we want to land a new flutter-based app store in 23.10. I write “new” because there’s prior art that’s helped jump start this (big shout out to @frederik-f from the community here). I’ll provide more details in a separate post but I want to briefly call out two points:

  1. The App Store will support debs, but it’s a non-goal to try and present debs and snaps as two options for the same app. Doing that is hard to get right and restricts design choices in other areas. So, I’m describing this as a “snap-first app store” not because we won’t support debs, but because we’re designing the experience around snap metadata. Deb support will land later because resources are always tight (we’re a small team). Finally, nothing here stops users from installing applications the old fashioned ways.

  2. We’re also looking to simplify ratings with a +1 or -1 approach. This is similar to what Steam does, and they can still compute pseudo 5-star ratings while providing a simpler UX. Additionally, we could support other signals, for example, by computing the ratings slope one could image a “most improved” category.

To see what we’re aiming for in the 23.10 MVP see the overview below and let us know what you think:

Ubuntu Pro

The Bionic beaver’s 5 year LTS support period recently ended. This means new security updates are only available with an Ubuntu Pro subscription (its free for personal use up to 5 machines see - Ubuntu Pro | Ubuntu). Previously, Pro updates were not highlighted in update-manager which made things a bit unclear for users. So this pulse @elioqoshi designed an SRU-friendly visual refresh which we’re hoping to land in upcoming point releases. Here’s a sneak peak of some of screens:


@till-kamppeter provides a glimpse into the world of printing in his June update. Here’s a few highlights:

  • Landed cups-filters 2.0rc2 with SRU and security fixes from 23.04 and Fedora 38.
  • Landed fixes for the CUPS snap with help from @seb128, @jbicha, and @kenvandine.
  • Updated all the OpenPrinting Snaps to latest upstream and rebased on core22.
  • @till-kamppeter and @jamesh worked on issues with the cups-control snap interface helping pave the way for printing on core desktop.
  • For those of you attending #GUADEC join @till-kamppeter at the GNOME/GTK Printing BoF

Noteworthy mentions

  • Ubuntu 22.10 reaches end of life in July :wave:
  • GNOME Shell and Mutter:
    • 44.2 has been released for Ubuntu 23.10
    • 42.9 for Ubuntu 22.04 LTS is nearing completion of testing.
  • Mouse cursor smoothness is finally getting fixed! Starting with mantic in mutter 44.2-3ubuntu1.
  • Firefox 114.0.2 landed ty @bandali
  • @dloose landed many of the firmware-updater UI changes I mentioned in previous updates. You can take a look by running sudo snap install --edge firmware-updater … although unless your firmware is horribly out of date you might not see many of the changes.

That’s it for this pulse. Feel free to ask anything in the comments section and see you in a fortnight.


Director of Engineering | Ubuntu Desktop


Why is this post moved to the top every now and then… ? [edit: edit]

I’m not sure … speculating perhaps it happened when I made an edit? :man_shrugging:

1 Like

I believe this post has been wrongly interpreted by the people at omglinux they went on with a heading of Ubuntu/Canonical demoting Debs for Snaps with the new store ?
Now added a word "apparently" .
Thats creating a lot of heat in the comments even though from my POV the thing that was said here is that due to design and current resource/technological restraints deb is currently being at a lower priority, right ? seeing it as a way of indirectly killing deb may not go down well for image of ubuntu and canonical with both already facing quite heat(some legitimate and some reasonableness).


Although they did mention this ;

“It’s a non-goal to try and present debs and snaps as two options for the same app. Doing that is hard to get right and restricts design choices in other areas,” he writes.

“Deb support will land later because resources are always tight. Finally nothing here stops users from installing applications the old fashioned ways.”

This is a confusing statement.

At the time of writing, Ubuntu’s Flutter-based software app already lets you install DEB versions of software also available as a Snap. It also makes it possible to only search for DEB software, as well as update DEB software. So… surely those “tight resources” aren’t required? 

There’s no intention to directly or indirectly kill debs but I appreciate the scepticism and I hope we can, in time, show it unwarranted.

We don’t have unlimited resources and so I’d rather provide a cautious estimate at this stage in terms of if deb support will be good enough for release. It’s better to under commit and over deliver than the opposite!