On Sunday, 1 December 2019 04:00:19 CET Ben Cooksley wrote: > On Sun, Dec 1, 2019 at 10:17 AM Volker Krause <vkra...@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
Description: This is a digitally signed message part.