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

[Thomas Lübking]

Am Tue, 15 Nov 2011 15:20:44 -0500
schrieb Scott Kitterman <kde at kitterman.com>:

> > a) drain sources from KDE frameworks
> 
> Only if the people that would work on this would otherwise work on
> KDE Frameworks.  AFAIK, that's not the case.
If one wants a feature in future KDE versions and such fork wouldn't
exist, one would not add it at all rather than to the frameworks?
Doesn't make any sense to me, sorry.

> I'm not aware of any cases where people wanted a new feature where
> they didn't also say they would forward port it to KDE Frameworks. 
The major issue is a pot. time gap. People show up, add things they're
interested in and then leave. Happens.
It might not in all occasions be possible to add it to kdelibs and
frameworks at the very same time.


> I don't think it's a wast of energy to provide useful features to
> users.
And I didn't say so at all, please don't put things into my mouth.
But if something /is/ added to kdelibs and lost in the frameworks, it's
been a waste.
If a fork of kdelibs makes a merge to the frameworks impossible in
reasonable time, all work on the frameworks was wasted.
You do not question that, do you?

> It is a mistake to assume that resources in FOSS projects are 
> fungible.
That is generally a valid argument, but applied on the wrong case.

> Just because people are prevented from working on kdelibs
> in 4.8, doesn't mean more resources are available for KDE Frameworks.

We're not talking about the "i'm working on the windowmanager and
cannot fix akonadi at all" situation. Entirely not.

kdelibs or frameworks are not features but locations, but people are
interested in feature, not in locations.

Eg. Valentin wants his SecretService to be used by KDE software - if
that means to add it to frameworks, he'll add it there. If it means to
add it to kdelibs, he'll add it there.
Everything else would be religious nonsense.

> kdelibs is already open.
I am not talking about downstream patches. If individual distributions
like to backport things (happens and has happened a lot) or add
"proprietary" stuff, that is completely different from opening the API,
sorry.

But the issues start, when those downstream changes get coordinated into
a fork.

> I fail to understand it either
You really meant: "Why not add it to the application (link static) and
put it into frameworks later"? (as i wrote.)

> It's already happening, so the real question is how to minimize the
> impact.
This is why i've posted this mail in the first place.

"Minimizing the impact" means to align up- and downstream, ie. find
a way to provide features *now* w/o really opening kdelibs to new
features but at best accelerate frameworks development.
(as you probably read in the rest and unfortunately not commented part
of my original post)

Cheers,
Thomas