How to handle KDE not respecting YOUR distros requirements?

[Thomas Pfeiffer]

On Montag, 28. März 2016 00:52:38 CEST Luca Beltrame wrote:
> In data domenica 27 marzo 2016 21:27:15 CEST, Richard Brown ha scritto:
> > They made it clear what they were going to do in advance, and
> > communicated how and when they will get there. They never delivered
> > anything less than they promised.
> 
> To be honest, as far as I understand, the "other camp" has a significant
> involvement of major stakeholders, which can at least suggest (I would not
> say influence, because I am ignorant and I don't want to give wrong
> assumptions) a direction to take.
> 
> While there are companies involved in KDE software (KDAB, Kolab Systems,
> Blue Systems) there is no real "stewardship" because, as I mentioned
> elsewhere, there's no "governing body" for KDE.

This is really a key point about which - as we've learned over the recent 
months - there still seems to be quite some misconceptions.

As Lucas said: There is no single governing body for KDE. The only legal 
organization which represents KDE, the KDE e.V., explicitly stays out of any 
decisions related to our range of products.

Each project within KDE makes their own decisions, they report to nobody but 
themselves.

> > much an unspoken mystery, and the modularisation makes it harder to
> > interpret what that purpose might be
> 
> Frameworks - add-ons to Qt with varying level of dependencies to develop
> software (they're also used in other, non KDE software applications)
> Applications - well, the name says it ;)
> Plasma - the actual "DE"
> 
> Applications and Plasma depend on Frameworks, but Applications do not depend
> on Plasma, nor does Plasma depend on Applications.

Although I'm still convinced that it makes sense to market Plasma, individual 
Applications and Frameworks separately, we're still having a hard time making 
the distinction clear to the outside world.

We're aware of that, and we're working on improving the communication of this. 
Does anyone here maybe have ideas on how we could make what Luca said above 
clearer to the public?
 
> > Maybe, but right now my perspective is Plasma is overly complicated to
> > track changes, understand changes, adopt changes, and deploy..
> 
> The most pressing issue is due to dependency and communication of
> modularization (see below).
> 
> > Will do my best to encourage one of openSUSE's actual KDE packagers to
> > reply there with absolutely concrete examples, rather than fill up
> 
> Most of this falls into the "dependency discussion" that was mentioned
> before. Splitting isn't a huge problem if:
> 
> - it's communicated *early*
> - the depedencies between modules are clearly defined (it is so for
> Frameworks - that's why Tiers exist)
> 
> Some of the issues we solve by tracking development ourselves, although
> that's not always optimal.

Again: Any ideas on how we could improve this? Which information does 
distributions need and in which form?
 
> > Look at doing something like GNOME Continuous https://build.gnome.org/#/
> 
> There is: https://build.kde.org - the problem at the moment is that it's a
> one woman show with help with the severly overworked KDE Sysadmin "team".

> > or maybe even phase 3, as you should be testing stuff before anyone
> > submits anything to a code tree.. There's infinite examples of

> (Switching hats to KDE now)
> The main problem is that the CI system is undergoing a complex transition
> (and IMO, too much for a single person to handle) and it's often broken due
> to that (not to mention the quirks of the base distro used, see e.g.
> libhybris in Ubuntu).  This is where more community involvement would help,
> but I realize doing this is a mostly thankless job.

Is this maybe something that openSUSE could help us with? You guys seem to 
have much more experience with CI than we do, and you have infrastructure that 
is proven to work.
If you could support us in this are, you would of course benefit by having 
already better tested code to work with.

Cheers,
Thomas