KF6 meeting notes 2021-04-17

[Luigi Toscano]

Hi all,

the meeting started without a fixed agenda but nevertheless the "needs input"
list is much shorter now, thanks everyone!

Please see the notes below, especially Plasma people :) and feel free to
comment if I've missed anything.

--------------------

Question about the removal of support for Qt <5.15 -> most #ifdefs have been
removed, the remaining will be taken care of

Several "needs input" tasks are related to Plasma.
Maybe it would be better to focus on Plasma next time and involve Plasma
people, and find out which tasks are really blockers for KF 6.0 and which are not.
In fact several Plasma items are not really blockers for KF6.

In the worst case, the first plasma-frameworks release could be delayed until
Plasma 6 is closer to be ready. Other frameworks don't depend on it (just one
dependency in KRunner, but it is deprecated, to be removed at branching time).
Maybe frameworksintegration? (to be checked)


https://phabricator.kde.org/T11587 "Investigate making KColorScheme tier1" ->
big impact on the dependencies, probably require some priority in the discussion.

https://phabricator.kde.org/T11557 "Change policies/design guidelines" not
really needs input, moved to metatasks.


https://phabricator.kde.org/T11927 KScreen for KF6 -> not really KF6 related,
just in the way that some cleanup can happen at the KF6 transition time. =>
KF6 tag removed, add Plasma 6

Question on https://phabricator.kde.org/T12083 ("Make DBus dependencies
optional"), should we have a unified cmake option for disabling it, or should
it be just per-framework?
=> First: try to do the right thing on each platform automatically (use/not
use by default). If there is a use case for supporting compiling both with and
without, make it explicit.

https://phabricator.kde.org/T14355 "Add base class for QWidgets and QML KCMs"
-> should we just it move to "do it at branching time"? Probably yes, having
the base,  non-visual part of the classes in a common, non GUI-dependent place
makes sense (basic MVC). It will help to solve some related tasks like
https://phabricator.kde.org/T13140.
-> moved away from "needs input".


https://phabricator.kde.org/T11982 "KF6 and STL compatibility" -> the title is
a bit misleading, it is about KRandom only and the work has been already done.


A few Plasma theming tasks have been merged into the main one
(https://phabricator.kde.org/T13467), as they were in the end all about the
same topic.

https://phabricator.kde.org/T12296 "Remove KRegExpEditorInterface usage"
basically done, the only user left is still commented. This sparked off a bit
of discussion (again) around the definition of done for a porting tasks (how
many porting is needed to say that such a task  can be moved to "done"? At
least some important use cases). Regarding this specific task, given that the
maintainer of the code has actively commented out the code, the task can be
considered as done. -> moved

https://phabricator.kde.org/T12093 "Kill KRandom" it seems to be done, even
though the title can be changed (some methods have no replacement so they can
stay, but everything else is replaced by Qt class)

A suggestion for the next meeting (part of the "require input from Plasma
people" bucket):
https://phabricator.kde.org/T14335

https://phabricator.kde.org/T11584 "Migration plan for
KCoreAddons::Kdelibs4Migration classes" -> ticket updated, a removal is
probably possible without problems (we may need  some documentation in case
users would like to manually restore some very old kde4-era configuration)

https://phabricator.kde.org/T11563 "Define and communicate set of "blocking"
modules" -> either we consider it done, or it is a metatasks. Nothing that can
be worked on.

Ciao
-- 
Luigi