This starts to become a dangerous path (Was: New Feature for kdelibs)

[Thomas Lübking]

Am Tue, 15 Nov 2011 13:17:45 -0500
schrieb Scott Kitterman <kde at kitterman.com>:
> It is probably worth a discussion on packagers to share cross-distro
> ideas about what kdelibs feature patches to ship with 4.8.

While Scott's suggestion to have a commonly downstream patched
kdelibs 4.8 may on first sight seem to make a lot of sense, this is
essentially the path to a major fork of kdelibs.

I guess nobody does or would like such situation, since it will
a) drain sources from KDE frameworks 
b) eventually lead to a lead lock, since if applications (a library
    itself is worth nothing) start to rely on that features (4.8, 4.9,
    4.10?!) which have been added to the fork but not been integrated
    (this way) into frameworks, the applications are spellbound to the
    fork to avoid a regression - or porting things from kdelibs into
    vivid (ABI/API stable) frameworks, what to avoid all this trouble
    is about in the first place.
c) ultimately waste energy to either or both and the work to resolve
    the result

---

Now while I can empathize with those who wish to see their feature
upstream as fast as possible, I fear Kevin and others do not see the
pot. struggles of opening kdelibs.

KDE frameworks is essentially the approach to segregate kdelibs, what
is hard enough on a frozen object but completely impossible on a
"living" being - at least under the conditions of KDE development.

To do so it would be necessary to intercept each and every feature
commit to kdelibs, inspect, channel, sometimes stall and ultimately
merge it to KDE frameworks.
While adding a second parameter to a function is a nobrainer, adding
complete classes will require to rethink the constellation of
the frameworks and that should happen as early as possible, regarding
both, frameworks and the new feature.

I am sorry to say, the open structure of KDE is a great thing, but it
completely lacks the discipline and hierarchy for such (see Valentine's
SecretService merge - no offense, i've don worse) and I doubt anyone
wanted to buy in /that/ at all (because it'll kill the fun part)

(As a sidenote: I also slightly fail to understand the prohibition to
implement the new feature in the client(s) and keep it there until the
final move to KDE frameworks, but that's not important)

---

On the other hand, this is free Software, written by many free
individuals - for free and personal joy.

This makes it impossible to just say: "kdelibs is frozen" and that's it.

If the pressure to break the freeze grows to strong, people and
esp. distros /will/ work around that, with the option for
the unfortunate implications mentioned in the first paragraph.

One simply cannot command or forbid things and force people to apply to
that rules.
Instead one has to take a soft path [1], because getting things done
right is not invalidated by peoples minds.

---

On the search to a solution of this conflict, i started to wonder
whether the option to 

    grow KDE frameworks under kdelibs

has been discussed, ie.

- make KDE frameworks an (API/ABI unstable) hard dependency of (API/ABI
  stable) kdelibs (now, ie. 4.9 - 4.8 is a little late i guess ;-)
- move functionality from kdelibs to frameworks and leave "wrappers"
  behind.
- all new features HAVE to be added to KDE frameworks but it is ok to
  add a (API compatible) "wrapper" to kdelibs as well

Once frameworks are in a usable shape, applications can start to move
there (minor API adjustments, re-linking) and ultimately (and at some
point defined, communicated and FIXED) deadline, the shallow kdelibs
wrapper can be slipped away and frameworks will be the only source of
whatever KDE is called then.

Thanks for reading until here,
you can now safely stop and say

Cheers,
Thomas

[1] http://en.wikipedia.org/wiki/The_North_Wind_and_the_Sun