Blacklisting of PIM from the CI system

[Volker Krause]

On Tuesday, 3 December 2019 22:13:43 CET Allen Winter wrote:
> On Tuesday, December 3, 2019 2:52:31 PM EST Volker Krause wrote:
> > 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.
> 
> Silly questions
> 
> Why do we need 50-60 repos to build kontact?
> why not 1 repo for kontact and all its stuff? (I miss kdepim)
> 
> do Krita or any of the other large applications have so many repositories
> devoted to them?
> 
> After all these years since the svn->git move I still understand why so many
> repostitories for Kontact. For frameworks it makes sense, but I don't get
> it for applications

50 repos for this is too much IMHO, I agree. There's reasons for not having 
this in a single one though, one being that various parts are used externally 
as well (former kdepimlibs basically). This is what we try to address with 
moving things to Frameworks. There's also things like Akonadi or Kleo being 
used externally though, that's much harder to Frameworkify.

And then there are a few obsolete reasons, like the refactoring done for 
Kontact Mobile 10 years ago, or for Kube.

Another aspect to look at is whether those repos have a well defined scope. 
Good examples are IMHO eventviews/incidenceeditor, bad ones are libkdepim/
kdepim-apps-libs/pimcommon/etc. The former hurt much less than the latter I 
think.

The strategy discussed at the PIM meetings for this is two-fold: continue with 
Frameworkification of the well-scoped and externally used modules, and try to 
dissolve the libraries with undefined scope by moving stuff to more 
appropriate places. Especially the latter isn't exactly a fun job, therefore 
this is progressing very slowly.

Going to a mono repo setup would make building easier for PIM contributors, 
but it would not solve the problem for new people to find their way through 
the various libraries with unclear scope, so IMHO this is a problem we have to 
address regardless of the repo layout.

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/20191204/05aa2307/attachment.sig>