Blacklisting of PIM from the CI system

[Volker Krause]

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
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20191203/f496e6e5/attachment.sig>