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

[Scott Kitterman]

On 11/15/2011 04:08 PM, Thomas Lübking wrote:
> 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.

That's true, but the question is when.  For developers focused on more 
near term things than Frameworks, it's unlikely they'll help with 
Frameworks in order to get their feature out faster.  Are there any 
examples of people who started working on the Frameworks port because 
kdelibs 4.8 doesn't exist?

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

That's true. I think that improves the case for doing the work to 
support 4.8.

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

I agree with that, but we are talking about a limited number of features 
required for specific applications, not a free for all of feature 
changes for change sake.  I think 'fork' is a very strong word and it's 
really overkill for the case we're discussion.

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

I agree.  This isn't about capability, but timelines.

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

They are also interested in timeframes.

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

It also means that if there are applications making use of it before KDE 
Frameworks is out, then it'll be left to distros to figure out how to 
stitch it together with the existing kdelibs to make it work (or just 
give up on the newer applications/features).  Unless no one will make 
use of the work for things that are released before Frameworks is 
released, keeping it out of kdelibs just makes things harder for 
distributors.

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

Fortunately no one is talking about doing that.

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

No.  I meant I don't understand how telling people their work can't go 
into KDE SC 4.8 will incentivize them to work on Frameworks.  If they 
are interested in Frameworks, they're probably doing it already.

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

I did read that part, but didn't comment on it.  Since I'm not involved 
in Frameworks development, I've no opinion on if something like that is 
feasible.  My suspicion is that KDE Frameworks will stay on the path 
it's on and the rest of us need to figure out how to deal with it.

Scott K