KF6 BoF Akademy Notes 2021-06-21 Topics: - how to continue and when to branch for a Qt 6 port - implications of Kevin's talk - better time for the weekly call - better priorities on the task board
Branching: - Plasma and things depending on shadertools/RHI would like this to be done earlier than later - a lot of stuff can be done without branching, and doing that in a single place avoid duplicate effort Prioritization: - use the weekly calls on classifying which tasks are blocking Weekly call: - do a doodle poll for this, David E takes care of it (https://doodle.com/ poll/94646r75keyxgqkx?utm_source=poll&utm_medium=link) Current status: - Nico got several of them building, but some needing dirty hacks - KIO has been problematic due to depending on removed Qt API (text codecs, network config) - KCodecs has QTextCodecs in its public API - we can use the compat library where we only need this internally, but for KCodecs we need a proper soluition for that - KCodecs alternative codec name mapping might be obsolete meanwhile (see KCharsets::codecForName), can we remove that? - QNetworkConfigurationManager: Qt 6.2 has new API for that, just isMetered() is missing, but that's nothing KF needs. - some of the source-incompatible changes can be done now already inside #ifdefs, if they are somewhat contained - https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/108 still needs work - should cmake install variables contain a major version? probably not => rename KXMLGUI5DIR to KXMLGUIDIR, and so on => do this now - KNotification has behavior changes (removing of non-API features): announce those in the monthly release notes - QML bindings go into the corresponding frameworks, with the QtQml dependency being optional where needed - for the new QML binding API: https://bugreports.qt.io/browse/QTBUG-92258 will help (Qt 6.3) - possibly look at doing the kdeclarative breakup now to identify C++ APIs needing improvement for simplifying bindings - do a KDeclarative breakup BoF for a case-by-case review for things to (1) move, (2) remove, (3) rework/redesign to current standards, David E schedules the BoF: Tuesday 9am UTC in room 2 Frameworks types and tiers: - metadata for types is unreliable - should we drop the types or replace them with something else? - messages we want to convey with this: (1) cross-platform/platform-building/ Plasma specific (2) runtime dependencies during deployment - information about supported OSs don't fully cover that - whether plasma specific libs should be shipped as part of kf first depends on all wrong dependencies getting fixed first - split releases might make it harder for apps to integrate Plasma-specific things - however already the case in some places, like Kate's depending on the breeze style - how to proceed: (1) just new labeling, (2) same time release of two differently named library sets, (3) release plasma frameworks with plasma, (4) like (1) but move daemons out to Plasma? - daemons should not be default-started outside of a Plasma session - review this on a case by case basis during the weekly calls
signature.asc
Description: This is a digitally signed message part.