Blacklisting of PIM from the CI system
vkrause at kde.org
Tue Dec 3 19:52:31 GMT 2019
On Sunday, 1 December 2019 04:00:19 CET Ben Cooksley wrote:
> On Sun, Dec 1, 2019 at 10:17 AM Volker Krause <vkrause at 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
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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 195 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel