The Qt Company is stopping Qt LTS releases. We (KDE) are going to be fine :)

Obvious disclaimer, this is my opinion, not KDE's, not my employer's, not my parents', only mine ;)

Big news today is that Qt Long-term-supported (LTS) releases and the offline installer will become available to commercial licensees only.

Ignoring upcoming switch to Qt6 scenario for now, how bad is that for us?

Let's look at some numbers from our friends at repology.

At this point we have 2 Qt LTS going on, Qt 5.9 (5.9.9 since December) and Qt 5.12 (5.12.6 since November).

How many distros ship Qt 5.9.9? 0. (there's macports and slackbuilds but none of those seem to provide Plasma packages, so I'm ignoring them)

How many distros ship Qt 5.12.6? 5, Adélie Linux, Fedora 30, Mageia 7, OpenSuse Leap 15.2, PCLinux OS (ALT Linux and GNU Guix also do but they don't seem to ship Plasma). Those are some bigger names (I'd say specially Fedora and OpenSuse).

On the other hand Fedora 28 and 29 ship some 5.12.x version but have not updated to 5.12.6, Opensuse Leap 15.1 has a similar issue, it's stuck on 5.9.7 and did not update to 5.9.9 and so is Mageia 6 which is stuck on Qt 5.9.4

Ubuntu 19.04, 19.08 and 20.04 all ship some version of Qt 5.12 (LTS) but not the lastest version.

On the other a few of other "big" distros don't ship Qt LTS, Arch and Gentoo ship 5.14, our not-distro-distro Neon is on 5.13 and so is flatpak.

As I see it, the numbers say that while it's true that some distros are shipping the latest LTS release, it's not all of them by far, and it looks more like an opportunistic use, the LTS branch is followed for a while in the last release of the distro, but the previous ones get abandoned at some point, so the LTS doesn't really seem to be used to its fully potential.

What would happen if there was no Qt LTS?

Hard to say, but I think some of the "newer" distros would actually be shipping Qt 5.13 or 5.14, and in my book that's a good thing, moving users forward is always good.

The "already released" distros is different story, since they would obviously not be updating from Qt 5.9 to 5.14, but as we've seen it seems that most of the times they don't really follow the Qt LTS releases to its full extent either.

So all in all, I'm going to say not having Qt LTS releases is not that bad for KDE, we've lived for that for a long time (remember there has only been 4 Qt LTS, 4.8, 5.6, 5.9 and 5.12) so we'll do mostly fine.

But What about Qt 5.15 and Qt 6 you ask!

Yes, this may actually be a problem, if all goes to plan Qt 5.15 will be released in May and Qt 6.0 in November, that means we will likely get up to Qt 5.15.2 or 5.15.3 and then that's it, we're moving to Qt 6.0

Obviously KDE will have to move to Qt 6 at some point, but that's going to take a while (as example Plasma 5 was released when Qt was at 5.3) so for let's say that for a year or two we will still be using Qt 5.15 without any bugfix releases.

That can be OK if Qt 5.15 ends being a good release or a problem if it's a bit buggy. If it's buggy, well then we'll have to figure out what to do, and it'll probably involve some kind of fork somewhere, be it by KDE (qt already had that for a while in ancient history with qt-copy) or by some other trusted source, but let's hope it doesn't get to that, since it would mean that there's two set of people fixing bugs in Qt 5.15, The Qt Company engineers and the rest of the world, and doing the same work twice is not smart.

git mr: easily downloading gitlab merge requests

With KDE [slowly] moving to gitlab you may probably find yourselves reviewing more gitlab based patches.

In my opinion the web UI in gitlab is miles better, the fact that it has a "merge this thing" button makes it a game changer.

Now since we are coming from phabricator you have probably used the arc patch DXXX command to download and locally test a patch.

The gitlab web UI has a a link named "You can merge this merge request manually using the command line" that if pressed tells you to


git fetch "git@invent.kde.org:sander/okular.git" "patch-from-kde-bug-415012"
git checkout -b "sander/okular-patch-from-kde-bug-415012" FETCH_HEAD


if you want to locally test https://invent.kde.org/kde/okular/merge_requests/80

That is *horrible*

Enter git mr a very simple script that makes it so that you only have to type


git mr 80




P.S: If you're an archlinux user you can get it from AUR https://aur.archlinux.org/packages/git-mr

P.P.S: Unfortunately it does not support pushing, so if you want to push to that mr you'll have to do some work.

KPatience added to flathub. Which app should be next?

This week we added KPatience to flathub.

That makes for a quite a few applications from KDE already in flathub



Which one do you think we should add next?

19.12 releases branches created

The branch naming has changed to try to accommodate for the stopping of the "KDE Applications" brand, it's now called
release/19.12

Make sure you commit anything you want to end up in the 19.12 releases to them

We're already past the dependency freeze.

The Freeze and Beta is this Thursday 14 of November.

More interesting dates
November 28, 2019: KDE Applications 19.12 RC (19.11.90) Tagging and Release
December 5, 2019: KDE Applications 19.12 Tagging
December 12, 2019: KDE Applications 19.12 Release

https://community.kde.org/Schedules/Applications/19.12_Release_Schedule

Cheers,
Albert

P.S: Yes, this release unfortunately falls in the middle of the debranding of "KDE Applications" and there's still a few things called "KDE Applications" here and there

[*] There's a small issue with kwave we're working on figuring it out

You can use a C++11 range for loop over a static array

void DeviceListing::populateListing(const show showStatus)
{
  const Solid::DeviceInterface::Type needHardware[] = {
    Solid::DeviceInterface::Processor,
    Solid::DeviceInterface::StorageDrive,
    Solid::DeviceInterface::Battery,
    Solid::DeviceInterface::PortableMediaPlayer,
    Solid::DeviceInterface::Camera
  };

  clear();

  for (unsigned int i = 0; i < (sizeof(needHardware)/sizeof(Solid::DeviceInterface::Type)); i++) {
    QTreeWidgetItem *tmpDevice = createListItems(needHardware[i]);
    deviceMap[needHardware[i]] = static_cast(tmpDevice);

    if ((tmpDevice->childCount() > 0) || (showStatus == ALL)) {
      addTopLevelItem(tmpDevice);
    }
  }
}

in C++11 you can rewrite it in the much easier to read

void DeviceListing::populateListing(const show showStatus)
{
  const Solid::DeviceInterface::Type needHardware[] = {
    Solid::DeviceInterface::Processor,
    Solid::DeviceInterface::StorageDrive,
    Solid::DeviceInterface::Battery,
    Solid::DeviceInterface::PortableMediaPlayer,
    Solid::DeviceInterface::Camera
  };

  clear();
 
  for (const Solid::DeviceInterface::Type nh : needHardware) {
    QTreeWidgetItem *tmpDevice = createListItems(nh);
    deviceMap[nh] = static_cast(tmpDevice);

    if ((tmpDevice->childCount() > 0) || (showStatus == ALL)) {
      addTopLevelItem(tmpDevice);
    }
  }
}

Akademy Guest Post: Some thoughts regarding discussion culture

First of all I want to say thanks for hosting me on your blog and letting me write this guest post!

I am Florian Müller from Germany, working as a Sysadmin at a small tech collective. I have been a KDE user for years, but I am quite new to the KDE community. This years Akademy was my first and I am looking forward to dive in deeper and contribute more to KDE.

I had a really good time at Akademy in Milano, got to know so many cool people and learned a lot about the KDE community and KDE in general. Thanks a lot to everyone organizing this unique event! I am sure it won't be the last time I'll attend Akademy.

I want to share some things I noticed about discussion culture, please feel free to criticize/discuss/comment, so maybe we can work out some guidelines for that in the future.
First of all some words about discussion culture in general. Because all people are different, we need technics to allow everyone to participate in group discussions. When people are not that confident in general, they tend to not raise their voices in bigger groups, also if they have opponent opinions to the main stream. So in order to have a greater culmination of creativity and ideas, we need to create an atmosphere to make it easier for everyone to participate.

One thing would be the setup of the room the discussion will be held in. Do you want to have a central speaker in the front leading the discussion or do you want to setup the chairs and tables in a circle so everyone is on the same level. Sometimes there are mostly lecture halls available, so time to plan in advance and ask for a different room has to be taken in accountance. The advantage of a circle is that everybody is able to see everyone else. We can also think about forming smaller discussion groups when possible and a topic can be split up into smaller parts.

Another point you can think about is how you organize the turn keeping. One could appoint a person who only deals with turn keeping. We could alternate the job of turn keeping from one discussion to the next. At the beginning of the discussion we should make it transparent on how turn keeping will work. For example we could have a rule that people who want to say something the first time, move to the top of the speakers list to make sure that rare voices will be heard. We could also have a speakers list alternated by gender. There could be a maximum time for speakers so that single people don’t dominate the whole discussion by simply talking others out.

There are many other aspect we can think about when we want to make group discussions more inclusive. With this post, I just wanted to get the discussion started, so we can improve on that in the future.

Here are some links to continue reading:

https://www.workingdigital.de/en/blog/post/respectful-culture-of-discussion
https://www.wikihow.com/Be-Good-at-Group-Discussion

You can reach me directly at mail@flo-mue.de.

Linux App Summit 2019 schedule is out!

We published the Linux App Summit 2019 schedule last week.

We have a bunch of interesting talks (sadly we had to leave almost 40 almost as interesting talks out, we had lots of awesome submissions!) ranging from flatpak and snaps to how product management is good for Free Software projects with some thought provoking talks thrown in to make us think what's the future of our platform.

I am going and you should totally come too!

The attendance is free but please register at https://events.linuxappsummit.org/