Following Qt Contributor Summit earlier last week, we had the KDE Frameworks 6 (KF6) Kick-off sprint at the MBition office in Berlin last weekend, to define what we want to achieve, and plan how we can get there for the next major iteration of KDE Frameworks.

KF6 sprint group photo.
KF6 and KDE e.V. board sprint participants, virtual David and some of our hosts

Summary

Others have already extensively covered what happened at the sprint:

For the full stream of information of almost everything that happened you can also look at the activity of the KF6 Workboard. I’m therefore just highlighting a few things here.

  • We agreed to spend more effort than we did in the previous major version transition on ensuring all major users (Plasma, maintained applications) are adjusted or at least are trivially adjustable. This should hopefully allow us to shorten the overall 5 to 6 transition period eventually.

  • Better separation between UI and logic is now an explicit design goal. That is, we should refactor the remaining places that show UI implicitly (anything from a message popup for error handling to a complex dialog to e.g. handle TLS errors) to allow for alternative UI implementations. That’s of course of particular importance for Plasma Mobile, as those hardcoded UI elements are typically from a desktop-only time.

  • Similarly, separation between platform abstraction and platform implementation is now considered as a guideline. The best example for this is KWallet, which provides an API for secure credential storage, and at the same time an implementation of that. On Plasma this makes sense (we need to provide that platform feature), on other platforms (Android, Windows, etc) using existing infrastructure is often more desirable though. For an application developer this difference is ideally hidden behind a platform abstraction API. This should also help to simplify deployment on non Linux-y platforms and provide the user with a more native experience there.

  • Continuing where we left of for KF5, we identified a number of simplifications in the dependency tree of the tier 3 frameworks that once implemented should make things even more lightweight and further simplify deployment.

  • Something that easily goes unnoticed behind all the code discussions is the work on managing and maintaining the licensing aspects of KDE Frameworks that Andreas is driving.

  • This was the first KDE sprint for me where we experimented with video conferencing in remote participants, very ad-hoc using the built-in microphone and camera of a laptop and Jitsi, which worked surprisingly well. In general I think this is something to explore further (e.g. invest in a bit better equipment and advertise this ahead of sprints), as it could make such events and thus the community in general more accessible.

Going Forward

During the sprint the KF6 Workboard exploded a bit due to 200+ new tasks being added. We therefore had to review the task management workflow as well. Kévin will elaborate on the details soon.

It’s worth noting that the vast majority of tasks isn’t blocked on the actual KF6 branching yet, which we don’t expect before mid 2020. So that’s a lot of things we can work on immediately, in Frameworks, Plasma and applications. For those of you that can’t wait to get their hands dirty, check the top of the backlog column on the workboard (sorting and classifying tasks is still in progress, but the top should be good to go).

Another important aspect of the workflow is the reporting step at the end, so we will be able to regularly report on progress on Planet KDE. Make sure to subscribe there if you want to follow how KF6 evolves!

Thanks

Productive sprints like this are only possible with the logistical and financial support from individuals and organisations. Thanks go to MBition and particularly our friends Agustin and Eike there for hosting us, and KDE e.V. for making sure once more everyone had a place to sleep.