Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
It’s already a month since we were in Spain for GUADEC and I still haven’t gotten around to writing something, so before I completely forget here are a few quick impressions and photos!
Local-FirstSimilar to last year, my main focus was on local-first, since that’s what I’ve mostly been working on recently. Julian and I gave a talk about Reflection and the p2panda-gobject bindings, and more generally plans for making local-first sync part of the GNOME developer platform.
Julian showing off p2panda-gobject during the BoF on SundayWe also had a local-first BoF to discuss system integration on Sunday, and a p2panda-goject workshop on Monday where we prototyped the Migrations app Jakub designed. Both were really well-attended, and it was super cool to see people starting to prototype their own little experiments that sync, including a collaborative Snake game, and a collaborative drawing app.
Blackboard at the local-first BoF with some notes on the Contacts and Sync portalsOur current thinking around system integration is that we wan to have two separate portals: one for Contacts, which would just manage P2P identities (so apps don’t have to each have their own identity system and contacts management), and a second one that actually syncs data on behalf of apps using a system API. For the former there is already a relatively detailed plan (see the talk linked above), and this will be prototyped as part of a p2panda NLnet grant.
This entire area is of course still experimental so all plans are subject to change, but it’s exciting to see things get more and more concrete over the past year.
TalksSome of my favorite talks:
The logistics of constantly going back and forth between the Rialta dorms, the University building, and the city center made the social side of the conference more difficult than in other years, especially because public transit stopped relatively early in the evening. As usual, the smart move would probably have been to stay in the city center, but that only goes so far if everyone else is staying at the official accommodation, which is far away. More generally, the A Coruña city center was cute, but other parts of the city felt really car-centric and not very fun to be in.
The view from the hill was pretty cool though :) MetaI found it a bit sad that once again, we didn’t manage to use the fact that so many people were together in person to make progress on resolving the conflicts of the past few years. I didn’t see it as my responsibility to take care of this, and I assume everyone else felt the same way. But here’s an idea for next year: An official “Conflict Resolution BoF”, chaired by a trained mediator.
If there’s any interest I’d be happy to co-organize something like this, but I wouldn’t want to be solely responsible for it.
More Photos Local-first workshop on Monday Philipp at the Design BoF The Mobile BoF People hacking at the university Traditional GUADEC dinnerSee you next year!
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Earlier this month, I published a post about the future of Boxes where I detailed the huge technical rewrite I have been doing, porting to GTK4, Libadwaita, and replacing our SPICE display widget with Libmks. Today, I want to share a structural decision that aligns with that vision and sets up the project for long-term health/sustainability.
I have formally submitted a proposal to remove Boxes from the core-developer-tools set in gnome-build-meta and transition it towards becoming an independent application (with the ultimate goal of applying for GNOME Circle once all criteria are met).
I want to dive into why I am making this move, what it means for users and maintainers, and why I believe this is the right path forward.
There is No Drama HereFirst off, let’s get this out of the way: there is zero drama between Boxes and the GNOME project.
Boxes continues to be built by the same core set of contributors, fully committed to the GNOME Human Interface Guidelines (HIG) and deeply integrated into our ecosystem. We aren’t stepping away from GNOME. We are simply right-sizing how Boxes is categorized, distributed, and maintained.
Why Boxes Shouldn’t Be “Core” (and Why Versioning with the OS is Outdated)The desktop Linux landscape is shifting toward image-based operating systems with atomic updates and immutability. In this model, the underlying operating system provides a slim, reliable base, while applications live on top and update independently at their own pace.
Tying a complex application like Boxes to the biannual GNOME release schedule is not useful anymore. It forces us to hold back features and bug fixes for months just to align with the OS cadence, when users should simply get updates when they are ready and stable.
Furthermore, virtualization isn’t an essential utility that needs to be pre-installed on every single user’s machine by default. Boxes fits much better as a targeted application users explicitly choose to install when they need it.
Flathub-First: Moving Fast and Ending Distribution BottlenecksAs a maintainer, maintaining separate code paths and stable branches for dozens of traditional distribution packages is simply not sustainable long-term. I can no longer afford to maintain multiple stable branches. Moving forward, I am simplifying maintenance down to one stable branch and one development/nightly branch. To make this sustainable, Flathub is our primary and only officially supported distribution method.
By bundling the virtualization stack in our Flatpak, we ensure that users get a much more tested, consistent, and working virtualization backend regardless of what operating system they are running.
Moving out of Core allows us to heavily discourage downstreams from individually packaging Boxes. Instead, distros should defer their users to the official Flatpak on Flathub. If you are filing bug reports or seeking support, the Flathub build will be the baseline.
Branding and Infrastructure ChangesTo reflect this independent status, a few logistical changes are happening alongside this move. We are dropping “GNOME” from the user-facing app branding. Going forward, it will simply be named “Boxes”, and we will soon be moving to a new website domain (which is currently being finalized). Importantly, our Flatpak application ID will remain org.gnome.Boxes for full continuity and compatibility. This means existing installations, user settings, and Flatpak configurations won’t break, and users won’t need to reinstall anything.
What’s Next?This change gives us the flexibility to release updates whenever features are ready, iterate faster, and dramatically reduce maintainer burnout, all while delivering a more reliable and consistent user experience via Flathub. Once we settle into this new cadence and finalize our transition, we plan to apply for GNOME Circle.
To set clear expectations on timing: since Boxes currently uses GTK3 in its stable releases, we will soon submit an application for GNOME Circle review following our GTK4/Libadwaita rewrite.
If the Circle application is approved before the GNOME 52 Alpha deadline, the plan is to proceed with the removal from core-developer-tools and transition to Circle in time for the GNOME 52 release in March 2027.
For distribution maintainers wondering about upcoming distro releases: distros targeting GNOME 51 can continue to package the GNOME 50 release of Boxes, which will remain supported for the standard lifecycle of that release. If everything goes according to plan, GNOME 52 won’t include Boxes in the core set anymore. At this point, please don’t package Boxes anymore.
Read more of this story at Slashdot.
Read more of this story at Slashdot.