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
