Snappy Sprint Heidelberg

I recently attended Snappy Sprint Heidelberg, the first Snappy sprint focused on upstream and cross-distribution collaboration.

Snappy is a technology with an interesting history: initially started to provide App Store-like semantics (atomicity, declarative security) for the Ubuntu Phone project, it has since expanded to be a platform for desktop application deployment (e.g. VLC), as well as server applications and the IoT space.

There were a number of productive discussions with people working on Snappy itself, as well as folks from Fedora, elementary OS, KDE, and elsewhere.

At the start of the week, Snappy was technically usable in several different distributions, but only shipped fully-featured (in the main distribution repositories, with confinement, etc) in Ubuntu. Some great progress was made on AppArmor confinement in Arch Linux, and there is currently beta support for confinement via SELinux.

Providing a full-featured Snappy experience in Debian has its challenges, mostly relating to the lack of a default LSM. While AppArmor in Debian is supported and there's desire to have it be the default in "buster", Ubuntu carries a number of patches that add additional functionality not yet present upstream. I'm not sure whether pursuing getting those patches merged is more viable than waiting for SELinux support in snapd, however.

I've agreed to co-maintain the snapd package in Debian, and am excited to see intentions to support building snaps on a variety of distribution bases. While I do not expect Snappy (or Flatpak, or AppImage) to replace distribution-maintained software in the foreseeable future, nor do I feel that's a desirable outcome, I do think offering users freedom to choose to use software via these systems in a safe manner is critical.

"Your release sucks."

I look forward to Ubuntu's semiannual release day, because it's the completion of 6ish months of work by Ubuntu (and by extension Debian) developers.

I also loathe it, because every single time we get people saying "This Ubuntu release is the worst release ever!".

Ubuntu releases are always rocky around release time, because the first time Ubuntu gets widespread testing is on or after release day.

We ship software to 12 Million Ubuntu Users with only 150 MOTUs who work directly on the platform. That's a little less than 1 developer with upload rights to the archive for every 60,000 users. ((This number, like all other usage data, is dated, and probably wasn't even accurate when it was first calculated)) Compared to Debian, which (at last estimate in 2010) had 1.5 million uniques on security.debian.org, yet has around 1000 Debian Developers.

Debian has a strong testing culture; someone once estimated that around ¾ of Debian users are running unstable or testing. In Ubuntu, we don't have good metrics on how many people are using the development release that I'm aware of (pointers welcome), but I'd guess that it's a very very small percentage. A common thread in bug reports, if we get a response at all, goes on as follows:

Triager: ((Developer, bugcontrol member, etc. Somebody who is not experiencing the problem but wants to help.)) "Is this a problem in $devel?"

User: "I'll let you know when it hits final"

Triager: "It's too late then. Then we'll want you to test in the next release. We have to fix it BEFORE its final"

User: "Ok, I'll test at beta."

Triager: "That's 2 weeks before release, which will be too late. Please test ASAP if you want us to have time to fix it"

Of course, there are really important bugs with hardware support which keep on cropping up. But if they're just getting reported on or around release day, there are limits to what can be done about them this cycle.

We need to make it easier for people to run early development versions, and encourage more people to use them (as long as they're willing to deal with breakage). I'm not sure whether unstable/testing is appropriate for Ubuntu, and I'm fairly confident that we don't want to move to a rolling release (currently being discussed in Debian, summary). But we badly need more developers, and equally importantly, more testers to try it out earlier in the release process.

To users: please, please try out the development versions. Download a LiveCD and run a smoketest, or check if bugs you reported are in fact fixed in the later versions. And do it early and often.

Sometimes things get complicated... (Handling upgrades from Karmic)

I'm the package maintainer for Autokey in Debian. Upstream recently changed from using GTK+ to Qt4, which caused more than one complaint from users of testing.

The GTK+ version of the package is published in Ubuntu 9.10 Karmic. While upstream is continuing to do regular releases of the GTK version, they are focusing on the KDE version and have changed autokey to refer to the KDE version, while renaming the GTK version (formally autokey) to autokey-gtk. To make matters worse, upstream releases both as separate tarballs, and the packages conflict with one another.  (due to technical limitations)

What's the proper proceedure for handling this in Ubuntu? Should -gtk conflict with autokey, replace it, with autokey-qt being available as an option, or should I just keep things as they are and have the package "change out from under" users when they upgrade?