I’m not looking forward 3.24

If you’re reading this post, please also read the one about GNOME 3.26. I’ll leave this post here for historical purposes, but you should disconsider what I say here.

Not until it’s fixed.

Those who follow my work are used to read my “Looking forward ” posts, and they appear to be quite popular. This cycle, however, I’m not looking forward the next GNOME release.

That’s because I’m disappointed.

Very disappointed.


#1 – GNOME Shell

UPDATE: I was told this is an Arch-specific issue.

UPDATE 2: This is not an Arch-specific issue. This is now fixed in bug 781194, and will be available in the next GNOME stable release.

Let’s start with GNOME Shell, which is the single topmost important piece of software for end users. I was super excited with the new Night Lights mode, because as you may know, I suffer from insomnia (and fixed many bugs when I couldn’t sleep!).

When it landed on Arch Linux’s gnome-unstable repos, I’m pretty sure I was one of the first ones to test it.

But Shell keeps crashing every ~4 minutes. After 5 or 6 crashes, it logs me out. Needless to say, I lost work multiple times. That’s incredibly annoying.

If anyone is experiencing that, please join us in bug 781194 for we’re trying to find out why those crashes are happening. Fortunately, Philip Chimento is super nice and is working day and night to find out what’s going on.

But that’s still disappointing.

#2 – WebKit2GTK+

UPDATE: This was a regression in WebKit2GTK+.

I try to use Epiphany. I really try. But no matter how much I try, it fails me every time.

Looks like I can’t use keyboard to handle my Google Inbox mails. That’s a show-stopper to me.

#3 – Calendar

UPDATE: Thanks Debarshi for explaining this. He states:

There is a reason why crashes reported by ABRT are marked as ‘private’. Like all backtraces, the ones on those bugs often have passwords and private data in them. I have seen a few over the years. Hence those bugs are only accessible to Fedora contributors by default. Which makes sense, because, as you pointed out, they are Fedora bugs, and users already trust the Fedora community to ship secure software.

Why am I disappointed with my own piece of software? Well, I’m not disappointed with Calendar itself, but with the bugs around it.

It all started with bug 778419.

As you might know, I’m very urgent when it comes to crashes on Calendar. Sometimes I stop urgent tasks to fix crashers as quick as possible. Recently, I received many complaints that Calendar was crashing, but I couldn’t reproduce any one of them and worse, the debug logs weren’t helpful.

Here enters bug 778419.

Appearently, there is a issue management thing called FAF in Fedora. Nice. And looks like it catches many bugs. Super nice! But then, why am I disappointed?

Well, it starts out with me not being a Fedora user, nor watching Red Hat’s bug tracker. GNOME is agnostic to distros, and should stay that way. That’s why we have GNOME Bugzilla instance running, right? So people can report GNOME bugs, in… well, GNOME bug tracker.

But that’s ok – I can eventually see FAF and have some downstream feedback. But here is the catch: appearently, some bugs are private. Isn’t is nice when you can’t see the issues of your own app? Even nicer when appearently downstream doesn’t really care to report those issues upstream. This is clearly stated in the bug.

Let me restate this: GNOME is agnostic to distros. I refuse to watch Red Hat’s bug tracker.

#4 – Software

I was super, super excited to try GNOME Software’s Flatpak integration. I never really used Software since it (i) does not behaves super great in Arch, and (ii) isn’t better than Arch’s pacman.

But I thought Flatpak would change this scenario. Flatpak is not great at command line, building a Flatpak repo is still way too hard for humans, and OSTree’s progress reports don’t really report the progress, but throw random numbers for you to figure out what’s going on. But I was hopeful that all we needed was a good UI for it.

Do I have to say how disappointed I was to see Software falling apart when installing and updating Flatpaks?

I won’t waste any paragraph describing how it fails. You just need to have Software, Flatpak and a repository to see the action.

At Last

Some of you might think this is a rage post. It is not. I use GNOME every day, and I am fixing GNOME every single day of the past 3 or 4 years. I wouldn’t use it if I didn’t love it. It’s indeed the best desktop environment for Linux to me. And I of course will fix every single issue I described here.

But I think we can do better. Much better. Of course, everyone can come here and say “well, you can fix that by yourself until I don’t”, but is that a good approach to this situation? We’re failing in maintaining and improving the platform, and that’s a serious, collective issue. We have unbelievably good hackers around, it’s not the lack of skilled people, nor resources, that is cracking us.

What can we do to improve?

I’ll leave this question broad and open like that, and I’d like to hear the opinions of the community. Let’s just try to keep the level of the respect acceptable.

By the way: Shell crashed 11 times, and I was kicked out of my session twice, until I could finish this article

23 thoughts on “I’m not looking forward 3.24

  1. I understand your feelings. The stabilizing-phase or what is named the hard 20% at the end is not happening inside GNOME. Only after GNOME 3.XX.2 most of the annyoing bugs are fixed. I caught myself already several times with the thought “Couldn’t Fedora first ship GNOME before Archlinux”, because most of the bugs get fixed as soon as the user-base becomes bigger with Fedora.

    Edge cases and hardware-related bugs are anyway hard to be fixed by the developers on their own, so beta-testing has to become a more relevant case. You will need more real-endusers and therfore distributions which offer an easy to install gnome-unstable (which doesn’t break the system or requires a reinstallation).

    Sadly I will myself never install gnome-unstable on my ThinkPad, it’s my working machine. But on the other hand, gnome-unstable would be nice on my desktop.


  2. There is a reason why crashes reported by ABRT are marked as ‘private’. Like all backtraces, the ones on those bugs often have passwords and private data in them. I have seen a few over the years. Hence those bugs are only accessible to Fedora contributors by default. Which makes sense, because, as you pointed out, they are Fedora bugs, and users already trust the Fedora community to ship secure software.

    You can ask someone for access. There is certainly no dearth of Fedora contributors in the GNOME community. I have personally opened up such bugs in the past after making sure that there is nothing sensitive in there.


    1. In fairness, ABRT has a heuristic to determine if a backtrace contains sensitive data, and only marks the bug private by default if so. But the heuristic is terrible. If your stack contains a hash table anywhere, then the backtrace will be flagged for “key”. I have seen hundreds of backtraces where “key” refers to a hash table. I have seen zero backtraces where “key” indicates a cryptographic private key. I first complained about this years ago and it’s just so absurd… I don’t even look when ABRT flags sensitive data in backtraces anymore, because it’s never right. All the false positives make it worse than useless. If only it didn’t match on “key”, I bet false positives would be reduced by several times over.


  3. If was possible to install a gnome-shell (or gnome full flatpak) we will be able to has more than one version installed at the same time, improving the tests on beta releases or new versions. The tests are more difficult if it can broke your system, that has to be working always.


  4. Well, that motivates me to fix your unspecified gnome-software flatpak bug. I think you probably want to try out the flatpak integration in Fedora, Arch has basically no people actually developing gnome-software.


  5. What can we do to improve?

    I’ve written this recently:

    BTW for me on Fedora 25 the GNOME desktop freezes a lot of times, the only solution that I found was to reboot in a tty. Now I’m (hopefully temporarily) on Xfce. On Xfce I don’t have freezes, so it’s probably a gnome-shell bug.

    I think the stability problem comes from multiple reasons. The things that come to my mind right now, in no particular order: some developers seem to write code in a hurry and as a consequence write lots of bugs. There are not enough unit and integration tests. A monolithic codebase with 60k lines of JS code not well unit-tested is a recipe for disaster. The code is not well documented. Lots of developers prefer to hack on a shiny new experimental feature than writing tests, fixing bugs, cleaning up the code, writing documentation, taking care of bugzilla, etc.

    Liked by 1 person

  6. If you report the keyboard shortcuts bug on WebKit Bugzilla, I can try to find time to investigate. Please prefix the bug title with [GTK] and select the WebKitGTK+ component. Also, provide a description of the keyboard shortcuts that you expect to work, since I’ve never used Inbox before.

    Then again, I wonder if it’s not the same as https://bugs.webkit.org/show_bug.cgi?id=169269


  7. How your interaction with your Redhat (or other distribution’s) package maintainer works is likely to vary widely from person to person.

    Personally, for Gnumeric, I like the way the Redhat package maintainer handles the front line, requests further information as needed, and brings me in when appropriate.


  8. I disagree strongly with your statement that this is due to failure to maintain and improve the platform. Maintaining and improving the platform is precisely why I even did this JS engine upgrade in the first place, which is likely where the Shell crashes started. I’m sure the other maintainers could say similar things.

    What could have been done differently? I don’t think it’s constructive to do all this finger-pointing (though it’s at least nice of you to point the finger at the software, not at the maintainers) and then not suggest an answer to that question.

    Specifically in the case of the Shell crash, I think the answer is we need more people to use the GNOME release candidate after the feature freeze. We had the JS upgrade to mozjs38 landed just in time for the 3.23.90 release / feature freeze, and since that was relatively late, we actually had a backup plan to revert back to mozjs31 if it caused problems. If you had reported these crashes back then, that’s probably what would have happened. But it’s too late now! I doubt anyone was testing it out in that period except me, and as we know, I have never been able to reproduce the bug.

    PS. I don’t think the Shell crash is an Arch-specific issue. Some others that reported it are on other distributions, although Arch is the only one where it happens so often as to be unusable.

    Liked by 2 people

    1. I’m sorry you feel that way. I just wanted you to know that I see you as part of the solution, not the problem, and I apologize if I didn’t state that clearly in my post. I understand that we (collectively; myself included) failed to find that specific issue in time, and now we (collectively; myself included) delivered it with a critical issue. This is not a one man’s fault, at all.

      You’re right; I didn’t test it before the release, and that’s completely my fault. But I believe the problem does not lie in who tested it or not; but how many people tested, and how do we advertise that.


      1. Teste GNOME Shell before the release is a little hard, jhbuild is not for everyone. We must have some distro packages or repository. On GNOME 2, we had an Ubuntu PPA with all new packages.

        So, Arch still include GNOME unstable?


      2. It’s not your or anyone else’s fault for not testing before the release. It’s not easy to do it. You kind of have to have a computer dedicated for testing, in case things break! We can hardly ask volunteers to do that. I realize my comment sounded like “people should have done that” when I meant “in order to achieve what you want, people would have to have done that.”

        My point is you can’t expect the level of quality you get from dedicated testing, without people doing the dedicated testing.

        Thanks for your help fixing the bug today.


  9. I’d like to take the liberty and ask (although I’m admittedly not a GNOME contributor, just an admirer and full-time user) – is there any means of an automated UI testing done on GNOME?

    I think that, although such a framework usually takes a good while to set up and implement – esp. for a complex platform such as GNOME – the ROI for doing it, for the long run, are huge and can solve many regressions and issues, or at least reduce their quantity a great deal.


  10. A bug in gnome shell that still gets me from time to time: In the sidebar in the overview you used to be able to drag a window from one virtual desktop to another – if you try this for (last few years) GNOME shell freezes.


    1. Wow, yeah, that is bad. That might explain some weird issues I’ve seen; I was trying to imagine plausible causes, not something as basic as this…


  11. An outstanding share! I’ve just forwarded this onto a colleague who was doing a little homework on this.
    And he actually ordered me dinner because I stumbled upon it
    for him… lol. So let me reword this…. Thank YOU for
    the meal!! But yeah, thanx for spending some time to discuss
    this issue here on your web site.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s