Re: KF6 sprint meeting notes 2021-04-03
On Sun, Apr 4, 2021 at 8:58 AM David Faure wrote: > On samedi 3 avril 2021 22:42:36 CEST Ben Cooksley wrote: > > On Sun, Apr 4, 2021 at 2:18 AM David Faure wrote: > > > Here are the notes from today's meeting (thanks Luigi ) > > > > > > Feature deprecation process > > > = > > > - when to deprecate a feature? Deprecation signals people that they > should > > > start porting, but on the other hand the users of a certain feature may > > > need > > > help and the new feature may require some stabilization; > > > - a change on a complex application (ex kmymoney) may require help from > > > both > > > the Frameworks developers and the application developers, both with > their > > > specific knowledge > > > - conclusion: deprecate as soon as the replacement is proven to be > > > effective > > > in relevant use cases, and the deprecation doesn't mean the people who > > > worked > > > on the deprecation stop working on the porting of the application > > > > > > Back on https://phabricator.kde.org/T14233 (ECM and multiple Qt > version) > > > = > > > > > > TODO: build a proof of concept with solution 2) (make sure > > > find_package(Qt) is > > > called explicitly before find_package(ECM)) with some real repository > and > > > see > > > how it looks like. Other discussions about the general solution. See > > > solution > > > 3 added to the task right now. > > > > > > Back on https://phabricator.kde.org/T14164 (Create version-less KF > cmake > > > targets) > > > === > > > > > > (brief summary from the sprint discussion, please check the task) > > > The perfect solution would be to accept both (versioned and > unversioned) > > > targets but write the correct one in the configuration files, but such > a > > > solution doesn't seem to be possible from the previous discussion (may > > > need > > > additional discussion with steveire, and changes in cmake) > > > > > > > > > Update on https://phabricator.kde.org/T13806 (KParts plugin cleanup) > > > === > > > > > > The feature is only used by Konqueror, so it can be moved to the > > > application > > > and removed from Frameworks > > > > > > Timeline for bumping dependencies? > > > === > > > (Qt 5.15, C++17, CMake >= 3.16). Already agreed (by distributions). It > > > needs > > > to be done (can happen now, since tagging just happened) and be > advertised > > > in > > > the proper channels (announce). Problem solved! > > > > If we could get a heads up when this is supposed to happen so I can > > decommission the Qt 5.14 CI jobs that would be appreciated. > > That should also avoid a flurry of failure messages to the list when > those > > jobs inevitably fail :) > > Very good point. Well, there's no time like the present :) > > Packagers agreed, 5.81 RC1 is tagged, so we're all set for bumping the > dependencies. Can you deactivate the Qt 5.14 CI jobs and let me know when > I > can go ahead? > Perfect :) The DSL Job is running currently - once it completes you can proceed. https://build.kde.org/job/Administration/job/DSL%20Job%20Seed/619/ > > Can you also confirm that all CI systems support C++17 (gcc >= 8, clang >= > 6, > or MSVC >= 2017) and CMake >= 3.16 ? > I assume so, but it doesn't hurt to make sure :) > Per https://build.kde.org/job/Frameworks/job/kcoreaddons/job/kf5-qt5%20WindowsMSVCQt5.15/138/consoleText we are running MSVC 19.24.28315.0, which appears to correspond to Visual Studio 2019 Update 4 (patch level 3). Per https://build.kde.org/job/Frameworks/job/kcoreaddons/job/kf5-qt5%20SUSEQt5.15/214/consoleText we are using GNU GCC 10.2.1 And lucky last, per https://build.kde.org/job/Frameworks/job/kcoreaddons/job/kf5-qt5%20FreeBSDQt5.15/199/consoleText we are running Clang 10.0.1 That should be more than sufficient on the compiler side i'd imagine :) With regards to CMake: Per https://build.kde.org/job/Administration/job/Docker%20Generate%20SUSEQt5.15%20Image/20/consoleText we are running CMake 3.19 On the Windows builders: C:\Craft\CI-Qt515\windows-msvc2019_64-cl-debug>dev-utils\bin\cmake.exe --version cmake version 3.17.3 And on the FreeBSD side: root@FreeBSDBuilderKappa:~ # cmake --version cmake version 3.18.4 That should also meet those requirements quite nicely. Cheers, Ben > -- > David Faure, fa...@kde.org, http://www.davidfaure.fr > Working on KDE Frameworks 5 > > > >
Re: KF6 sprint meeting notes 2021-04-03
On samedi 3 avril 2021 22:42:36 CEST Ben Cooksley wrote: > On Sun, Apr 4, 2021 at 2:18 AM David Faure wrote: > > Here are the notes from today's meeting (thanks Luigi ) > > > > Feature deprecation process > > = > > - when to deprecate a feature? Deprecation signals people that they should > > start porting, but on the other hand the users of a certain feature may > > need > > help and the new feature may require some stabilization; > > - a change on a complex application (ex kmymoney) may require help from > > both > > the Frameworks developers and the application developers, both with their > > specific knowledge > > - conclusion: deprecate as soon as the replacement is proven to be > > effective > > in relevant use cases, and the deprecation doesn't mean the people who > > worked > > on the deprecation stop working on the porting of the application > > > > Back on https://phabricator.kde.org/T14233 (ECM and multiple Qt version) > > = > > > > TODO: build a proof of concept with solution 2) (make sure > > find_package(Qt) is > > called explicitly before find_package(ECM)) with some real repository and > > see > > how it looks like. Other discussions about the general solution. See > > solution > > 3 added to the task right now. > > > > Back on https://phabricator.kde.org/T14164 (Create version-less KF cmake > > targets) > > === > > > > (brief summary from the sprint discussion, please check the task) > > The perfect solution would be to accept both (versioned and unversioned) > > targets but write the correct one in the configuration files, but such a > > solution doesn't seem to be possible from the previous discussion (may > > need > > additional discussion with steveire, and changes in cmake) > > > > > > Update on https://phabricator.kde.org/T13806 (KParts plugin cleanup) > > === > > > > The feature is only used by Konqueror, so it can be moved to the > > application > > and removed from Frameworks > > > > Timeline for bumping dependencies? > > === > > (Qt 5.15, C++17, CMake >= 3.16). Already agreed (by distributions). It > > needs > > to be done (can happen now, since tagging just happened) and be advertised > > in > > the proper channels (announce). Problem solved! > > If we could get a heads up when this is supposed to happen so I can > decommission the Qt 5.14 CI jobs that would be appreciated. > That should also avoid a flurry of failure messages to the list when those > jobs inevitably fail :) Very good point. Well, there's no time like the present :) Packagers agreed, 5.81 RC1 is tagged, so we're all set for bumping the dependencies. Can you deactivate the Qt 5.14 CI jobs and let me know when I can go ahead? Can you also confirm that all CI systems support C++17 (gcc >= 8, clang >= 6, or MSVC >= 2017) and CMake >= 3.16 ? I assume so, but it doesn't hurt to make sure :) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
Re: KF6 sprint meeting notes 2021-04-03
On Sun, Apr 4, 2021 at 2:18 AM David Faure wrote: > Here are the notes from today's meeting (thanks Luigi ) > > Feature deprecation process > = > - when to deprecate a feature? Deprecation signals people that they should > start porting, but on the other hand the users of a certain feature may > need > help and the new feature may require some stabilization; > - a change on a complex application (ex kmymoney) may require help from > both > the Frameworks developers and the application developers, both with their > specific knowledge > - conclusion: deprecate as soon as the replacement is proven to be > effective > in relevant use cases, and the deprecation doesn't mean the people who > worked > on the deprecation stop working on the porting of the application > > Back on https://phabricator.kde.org/T14233 (ECM and multiple Qt version) > = > > TODO: build a proof of concept with solution 2) (make sure > find_package(Qt) is > called explicitly before find_package(ECM)) with some real repository and > see > how it looks like. Other discussions about the general solution. See > solution > 3 added to the task right now. > > Back on https://phabricator.kde.org/T14164 (Create version-less KF cmake > targets) > === > > (brief summary from the sprint discussion, please check the task) > The perfect solution would be to accept both (versioned and unversioned) > targets but write the correct one in the configuration files, but such a > solution doesn't seem to be possible from the previous discussion (may > need > additional discussion with steveire, and changes in cmake) > > > Update on https://phabricator.kde.org/T13806 (KParts plugin cleanup) > === > > The feature is only used by Konqueror, so it can be moved to the > application > and removed from Frameworks > > Timeline for bumping dependencies? > === > (Qt 5.15, C++17, CMake >= 3.16). Already agreed (by distributions). It > needs > to be done (can happen now, since tagging just happened) and be advertised > in > the proper channels (announce). Problem solved! > If we could get a heads up when this is supposed to happen so I can decommission the Qt 5.14 CI jobs that would be appreciated. That should also avoid a flurry of failure messages to the list when those jobs inevitably fail :) > Possible point of discussions for the next KF6 meetings (so that people > are > around)? > == > Possibility: Plasma-related topics; KIO-related topics. Maybe solve lower- > level first? (QTextCodec - blocked on Qt regaining support on those old > codecs, state changed). > Proposed for next week's meeting: > - KGlobalAccel (T12063) > - KPluginInfo kcmservices (T13555) > - KSelectAction (T12097) > > See you next week! > > -- > David Faure, fa...@kde.org, http://www.davidfaure.fr > Working on KDE Frameworks 5 > > > Many thanks, Ben
KF6 sprint meeting notes 2021-04-03
Here are the notes from today's meeting (thanks Luigi ) Feature deprecation process = - when to deprecate a feature? Deprecation signals people that they should start porting, but on the other hand the users of a certain feature may need help and the new feature may require some stabilization; - a change on a complex application (ex kmymoney) may require help from both the Frameworks developers and the application developers, both with their specific knowledge - conclusion: deprecate as soon as the replacement is proven to be effective in relevant use cases, and the deprecation doesn't mean the people who worked on the deprecation stop working on the porting of the application Back on https://phabricator.kde.org/T14233 (ECM and multiple Qt version) = TODO: build a proof of concept with solution 2) (make sure find_package(Qt) is called explicitly before find_package(ECM)) with some real repository and see how it looks like. Other discussions about the general solution. See solution 3 added to the task right now. Back on https://phabricator.kde.org/T14164 (Create version-less KF cmake targets) === (brief summary from the sprint discussion, please check the task) The perfect solution would be to accept both (versioned and unversioned) targets but write the correct one in the configuration files, but such a solution doesn't seem to be possible from the previous discussion (may need additional discussion with steveire, and changes in cmake) Update on https://phabricator.kde.org/T13806 (KParts plugin cleanup) === The feature is only used by Konqueror, so it can be moved to the application and removed from Frameworks Timeline for bumping dependencies? === (Qt 5.15, C++17, CMake >= 3.16). Already agreed (by distributions). It needs to be done (can happen now, since tagging just happened) and be advertised in the proper channels (announce). Problem solved! Possible point of discussions for the next KF6 meetings (so that people are around)? == Possibility: Plasma-related topics; KIO-related topics. Maybe solve lower- level first? (QTextCodec - blocked on Qt regaining support on those old codecs, state changed). Proposed for next week's meeting: - KGlobalAccel (T12063) - KPluginInfo kcmservices (T13555) - KSelectAction (T12097) See you next week! -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
