KF6 sprint meeting notes 2021-04-03

[Ben Cooksley]

On Sun, Apr 4, 2021 at 8:58 AM David Faure <faure at kde.org> wrote:

> On samedi 3 avril 2021 22:42:36 CEST Ben Cooksley wrote:
> > On Sun, Apr 4, 2021 at 2:18 AM David Faure <faure at kde.org> 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 at FreeBSDBuilderKappa:~ # cmake --version
cmake version 3.18.4

That should also meet those requirements quite nicely.

Cheers,
Ben


> --
> David Faure, faure at kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20210404/b68406ff/attachment.htm>