Some four or five weeks ago, being one of the teams maintaining a mutter-based distro, We were extremely happy with where we were. In this cycle, we worked hard to fix a number of old(er) minor issues, and we developed quite a few new things on top of our desktop, specific to our distro. As a team, we spent quite some time and effort to make sure everything worked rock solid, and it did. Preparing for a relaxed ride to release date.
This optimism turned out to be unjustified. Not much later, the first issues, caused by external developments, started to occur. Silently, there was an apparent change in definition of gdk_x11_window_get_frame_extents, causing issues on our upstream desktop, breaking some of the applets. Timing was bad, but hey, we’re not that easy to catch; problem was identified and fixed in a PR. Then our freshly developed, integrated screenshot app broke, due to the fact that full-screen windows all of a sudden needed an explicit no-decorators setting (transparent overlay window). Again, silently introduced at an awkward moment, just before release, but hey, let’s not nag, just identify the cause and fix.
These issues however turned out to be just the precursor to what had yet to come; a true deluge of fundamental changes to the underlying stack, causing all sorts of issues all over the place. Every day a new surprise. Some we could work around, some we won’t be able to fix within a reasonable amount of time. Apart from these challenges, the “bonus” is a large number of major, currently unfixed issues in mutter.
The brief recap of just the most serious issues we were confronted with in just the few weeks before release:
- Numerous last-minute changes in the underlying stack, forcing us to work around the clock in an attempt to fix before release date.
- Often, we see the resize cursor where there is nothing to resize (in the middle of a window).
- Dragging down a maximized window by its title bar makes the window jump down, either completely below screen area, or at least the cursor separates from the title bar.
- The window rectangle does not match the actual window size: Super + drag works well outside the window on certain types of windows
- At seemingly random occasions, the cursor is not scaled according to scale settings (200%-100%), resulting in a teeny tiny cursor
- On some types of windows, a double sized title bar (vertically) appears on some themes, or title bar becomes invisible at all.
- Clicking the title bar of certain types of windows does not focus the window.
- Some windows (like vscode) can’t be grabbed by their title bar at all.
- The title bar text of the update window’s progress bar is almost unreadably small (this is on gnome-shell, all at simply 100% scaling!).
- On none of the (3) boxes with Ubuntu with gnome-shell (on XOrg), a restart or shutdown is possible without holding the reset button.
- With touchscreen, on touching the screen, cursor disappears to never come back without a restart. Cross-checking on Ubuntu with gnome-shell (on XOrg): the desktop freezes completely on first touch.
Most of these issues are mutter related. Not all though. They are no exceptions, but occur on all kinds of hardware. All issues were furthermore cross-checked on regular Ubuntu with gnome-shell on XOrg, to make sure they are not specific to our desktop. Many of these issues were reported by us or by others. Not all (yet), because we need our time to create workarounds for coming release where possible.
Also many of these issues should be considered real show stoppers. No matter if it’s an in-between release or an LTS.
While any of these issues would make a bad impression on it’s own, the whole bunch probably makes the worst release we’ve seen in a long time. Imagine this is the first time you would try out Ubuntu. We should remind ourselves this is not just a wild experiment, this is Ubuntu. Let’s at least make clear to ourselves that it’s not acceptable what just happened.
Maybe there’s no simple solution to prevent this. We could ask ourselves however:
- Do we really have to chase the impossible short time frame from upstream and Ubuntu release date?
- Can we work closer with Gnome on one cycle, to shorten the development cycle by, let’s say, a month? Then we, as Ubuntu, can prepare and test early, rather than accept everything and be confronted with major breakage?
- Is there a way to have a daily ppa build of the upstream component we can build and test against, allowing earlier sight of key issues?
- Can we, collectively as desktop teams, have a go / no go decision, to accept some or all of a release, if things look decidedly bad to proceed?