Next weekend (March 27-28), we’ll have a virtual KDE Frameworks 6 Sprint. One and a half year after the initial steps towards KF6, the transition to Qt 6 is getting closer and we need to map out the next steps forward.

Should I join?

If you are asking yourself this question the answer is most likely yes!

In particular this is interesting for:

  • KDE Frameworks contributors, obviously :)
  • People working on non-Linux and/or non-desktop platforms.
  • Application or workspace developers making use of KDE Frameworks, or wanting to use KDE Frameworks.

And with this being virtual, dropping by has never been easier, you’ll find all relevant details in the wiki.

Topics

The wiki already lists a few possible agenda items, but I’d not consider that anywhere close to final yet, so please feel free to extend that.

Some of the topics I’m particularly interested in include:

  • When can we make Qt 5.15.2 the minimum required version across the board? That would enable more porting away from legacy Qt API, and most importantly the transition to version-less CMake targets.
  • How do we handle multiple Qt major versions in ECM? Most parts of ECM are entirely independent of Qt, so it might be possible to support both Qt 5 and Qt 6 from the same ECM codebase. This would simplify early tests with Qt 6, and simplify maintaining code bases that will need to support Qt 5 and Qt 6 for some time in parallel.
  • Reviewing stuck tasks and remaining porting blockers. Overall there has been great progress in removing such obstacles, with my PIM hat on I’m particularly happy about Carl’s recent success in porting the KMail account wizard away from Kross. But we of course need to make sure we aren’t missing anything that would cause unnecessary pain during the transition.
  • Discuss a branching strategy for KF6: When do we want to start with that, do we want to use the same approach for all frameworks or can we manage a sufficiently large amount of frameworks without branching and a few compile-time conditionals to justify a non-uniform approach?
  • Getting some feedback on the API draft for centralizing localization related functions around countries, country subdivisions, timezones, etc would be nice.
  • While the tier system introduced in KF5 has turned out rather successful, the type classification has been less relevant I think. Maybe it’s worth tweaking its categories a bit to improve that, using this to reflect whether a framework provides a “platform abstraction” or is meant for “platform integration”. A platform abstraction framework offers a unified API to functionality that is available by native APIs on the host platforms, such as e.g. KF5::Notification, something very valuable for application developers. A platform integration framework offers support with access a platform-specific feature that isn’t available everywhere, such as NetworkManagerQt or BluezQt, something more relevant to platform builders than (cross-platform) application developers.

Get Ready!

For preparation it’s useful to review, update and complete the KF6 Workboard, as well as the sprint agenda. Also pay attention to all times being in UTC there, while some countries transitions to daylight savings time during that weekend. See you on Saturday :)