[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-devel
Subject: Re: Blacklisting of PIM from the CI system
From: Volker Krause <vkrause () kde ! org>
Date: 2019-12-03 19:52:31
Message-ID: 11426609.O9o76ZdvQC () vkpc5
[Download RAW message or body]
On Sunday, 1 December 2019 04:00:19 CET Ben Cooksley wrote:
> On Sun, Dec 1, 2019 at 10:17 AM Volker Krause <vkrause@kde.org> wrote:
> > On Saturday, 30 November 2019 19:14:38 CET Ben Cooksley wrote:
[...]
> > > Fixing the current set of failures will not prevent this blacklisting
> > > action from being carried out - as a recurring issue it needs a
> > > permanent solution.
> >
> > What do you envision this permanent solution to look like?
>
> It's hard to say.
>
> Given the current problem, which is changes being actively made that
> break the build, the ideal solution would be the developers who are
> making these breakages to actively keep an eye on their jobs on the CI
> system.
That isn't an entirely fair statement IMHO, the changes triggering this were
perfectly fine with either the latest Frameworks release or a recent enough
master, just not the delayed master we had available on the CI at this point.
Seeing this hit other master-tracking builds too (e.g. OpenSuse in #kontact
this morning), I completely agree though this needs a better solution overall.
Tracking the latest release would be one approach, but from direct discussion
I understand that's currently not a viable solution due to Plasma's needs. Not
allowing changes for master compatibility (with the corresponding version
#ifdefs) is also counter-productive though, as it prevents early testing of
Frameworks changes (even if just locally). So the best I can think of is
making sure this situation is widely enough understood, and we have a way to
find out which exact revisions of Frameworks are deployed. Then we can maybe
get to the point where we can defer such commits until a recent enough
revision is available, which IIUC would usually take 48-72h.
> To avoid the issue with 'transient' failures due to new functions, etc
> being introduced to libraries then being used immediately in other
> projects, i'd suggest that the developers introduce a delay (30
> minutes should be sufficient) between the pushes to give the system a
> chance to build the updated libraries.
Agreed, for many people that's already standard practice I think.
> In the long run it would be
> nice to shrink the size of the PIM dependency graph, either through
> consolidating repositories or reorganising the code to cut the number
> of dependencies, which would reduce the number of times you'd need to
> wait.
The complexity of the dependency graph is also a problem for onboarding new
people, and with kdelibs4support gone IMHO the largest technical dept here.
It's being worked on, albeit slowly, currently we are losing ~1 module per
release I think.
Regards,
Volker
["signature.asc" (application/pgp-signature)]
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic