Blacklisting of PIM from the CI system
vkrause at kde.org
Wed Dec 4 16:59:27 GMT 2019
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
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.
-------------- 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