How to handle KDE not respecting YOUR distros requirements?

[Luca Beltrame]

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.

> Quality improved, but communication did not. Plasma 5 seemed like
> another sudden change and a reset to zero without learning many of the

That is where we disagree most even if we're in the same camp. ;) It was much 
better communicated that it was not meant to be for end users. And despite the 
large change that occurred in the desktop shell, it "mimicked" how the 
transition from Qt 4 to Qt 5 was, aka much less painful than Qt 3- > 4 was. 
Bear in mind that with the Frameworks is where KDE differentiated into 3 
different "offerings".

> 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.

> 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. 

> Maybe that can be read as a warning sign about KDE's own relevance in
> the future?

There is much that can be said wrt Unity and Qt, but this is not the place nor 
the time, and likely being off topic. 

> 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.

-- 
Luca Beltrame - KDE Forums team
GPG key ID: A29D259B
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/distributions/attachments/20160328/145e5522/attachment.sig>