Why can't invent's CI build eventview's release branch?

[Friedrich W. H. Kossebau]

Thanks for the instant reply, Ben.

Am Samstag, 4. September 2021, 22:16:08 CEST schrieb Ben Cooksley:
> On Sun, Sep 5, 2021 at 7:13 AM Friedrich W. H. Kossebau <kossebau at kde.org>
> 
> wrote:
> > Am Samstag, 4. September 2021, 18:59:19 CEST schrieb Glen Ditchfield:
> > > Eventview's release/21.08 branch builds successfully in Jenkins
> > > (https://build.kde.org/job/Applications/job/eventviews/), but not
> > > in invent.kde.org.  The most recent attempt at the moment is
> > > https://invent.kde.org/pim/eventviews/-/jobs/128298
> > > which fails during compilation:  one error message is `expected class
> > > name`.  It seems to be objecting to `CalendarSupport::PluginFactory`,
> > > which puzzles me, because calendarsupport's release/21.08 plugin.h does
> > > declare `PluginFactory`.
> > > 
> > > Could invent be using a broken version of calendarsupport?
> > 
> > Given this is the build of eventview stable/release branch, those items in
> > the
> > cmake log are suspicious:
> > "
> > 
> >  * KF5PimTextEdit (required version >= 5.18.40)
> >  * KF5IdentityManagement (required version >= 5.18.40)
> > 
> > "
> > which are indirect dependencies, so something wants the latest development
> > version here.
> 
> Looking at the .gitlab-ci.yml file, I see BRANCH_GROUP=kf5-qt5 which is the
> current development(master) branch group.
> Therefore what you are seeing here is expected behaviour.

Ah, I guess this is then due to not having seen an update after 21.08 
branching from master, 
The joy of metadata living in git repos themselves... :)

I guess you, Laurent, would want to update all that config then, being the one 
who seems to have related clue and also good mass-handling of PIM repos?

> > So, dear sysadmin :), could you please do a short status update e.g. to
> > the
> > community ML, to tell where we are, where things are tracked and who could
> > help with what to progress here?
> 
> We are getting fairly close now - the vast majority of the code for it is
> now ready with just one piece left to complete.
> Then we should be able to start a slow incremental rollout which will start
> with Frameworks (subject to initial testing completing okay)
> 
> Plasma will likely be the last to be supported by the new system because
> they require Frameworks master while also depending on a couple of Release
> Service items that will generally be expected to depend on Frameworks
> stable, and i'm not yet sure on how best to resolve that.

Thanks for the uodate. I would have been more happy if we could get such 
updates more often and in official places (or even better, documentated 
tracking of plans and state, so things are nut buried only in sysadmin heads 
with the low bus number). Most of us dislike to do documentation, I am aware, 
less fun, but in the end in the right does it avoids other non fun things.

Cheers
Friedrich