Manner in which kde-gtk-config development is conducted

[Michael Reeves]

On Sat, Mar 21, 2020, 10:27 AM Johan Ouwerkerk <jm.ouwerkerk at gmail.com>
wrote:

> On Sat, Mar 21, 2020 at 1:32 AM Ben Cooksley <bcooksley at kde.org> wrote:
> >
> > Comments welcome. Please note that simply fixing the dependency
> > breakage in this case is not enough to resolve this - there are
> > underlying issues which need to be addressed here.
> >
> > Regards,
> > Ben Cooksley
> > KDE Sysadmin
>
> I cannot comment as to whether or not this is a pattern of behaviour
> or just a few isolated instances. From a technical perspective I feel
> there are two (additional) underlying issues worth addressing here:
>
>  1. This could be prevented for the most part by having CI run before,
> and not after the fact. I.e. prior to merging code.
>  2. Different projects have different CI needs, and it would help if a
> project could safely manage their CI environment "on their own" as
> much as possible. The current system requires a lot of daunting
> (possibly otherwise unnecessary) complexity purely to manage the fact
> that a builder image will be used not just for one project but for
> perhaps the whole of KDE.
>

In regards to custom images kdiff3 has been using one since before
invent.kde.org came into being. The repo is mirrored on gitlab. Now that
invent.kde.org is up that setup runs the official ci as well. Since my
custom image is based on bionic it doesn't have the lastest kf5. This quite
recently cought a doc change made by some else that broke generation of
docs on older doctools versions. Both KDE's official CI and my personal
machine had the necessary kf5 version to build it and gave no error. Using
custom docker images is a great way of catching this kind of "works for my
setup issue".

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20200321/f6d3ca00/attachment.html>