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

[Scott Kitterman]

On 11/16/2011 11:31 AM, Aaron J. Seigo wrote:
> On Tuesday, November 15, 2011 16:28:21 Scott Kitterman wrote:
>> On 11/15/2011 04:08 PM, Thomas L�bking wrote:
>>> 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?
> 
> yes, though granted few, which is to be largely expected because frameworks is 
> new and in addtion despite coming to this list with a _consensus decision_ by 
> the _current maintainers and bulk of developers_ we have not received the kind 
> of cooperation and support that one might be led to expect from the KDE 
> community.
> 
> in any case, because i've been strict about this with libplasma2, people have 
> contributed to the frameworks branch (though sporadically as frameworks is 
> still fledgling).
> 
> beyond new people, it is just as important that this allows those of us who 
> are working on it to do so without spending time forward porting. every time 
> the KDE/4.7 branch changes, it slows us down as we then have to merge-and-fix 
> (both into frameworks as well as master, btw). realize, as noted already, that 
> as frameworks progresses these merges will become harder and more labor 
> intensive.
> 
> with the "let things flow into KDE/4.7" approach, controlled or not, we not 
> only lower incentive to work on frameworks but we make the efforts that are 
> going into frameworks less efficient. the math is very evident from that point 
> forward for what that means for frameworks.
> 
> again, we've walked this path before. we know how this turns out. we can 
> improve how we do things.

I don't see how any of that couldn't be addressed equally well with a
policy that said new features in kdelibs 4.x only after they are in
frameworks.  I don't think anyone would object to that and it would
avoid any negative impact on the people doing the bulk of the work on
KDE Frameworks (which I agree is an important goal).

>> 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.
> 
> agreed. i stil think there are significant risks for downstreams in this.
> 
>>> kdelibs or frameworks are not features but locations, but people are
>>> interested in feature, not in locations.
>>
>> They are also interested in timeframes.
> 
> agreed. and the answer is for us to get those timeframes together.
> 
> this is something i've committed to getting done since that ball got dropped. 
> the answer, however, is not to therefore make those working on frameworks 
> harder, which is like working around a bug when we can just as easily fix the 
> bug.
> 
>>> 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.
> 
> we are already doing this with kactivities, however. and will be doing so with 
> ksecretservice. so your concern is simply unfounded.
> 
> i think i may see a very important stumbling block here: many of us are still 
> thinking of kdelibs as a monolithic thing. frameworks is going in the other 
> direction and increasing modularity (we will be keeping the monolithic option 
> for those who don't want to be bothered with a dozen new repos :)

Except in kdelibs 4.x, it is monolithic like that, so just shoving
features into a branch somewhere for people who are interested in it
doesn't help distributors that want to try and support the widest
variety of use cases.

> the only issue is with new features to existing libraries (and we've worked 
> around this for KWallet...) and then it's like _any other kdelibs release_: it 
> will be in the next feature release. we want this cycle to be medium length: 
> it will be more than the usual 6 months, but if we coordinate together we can 
> make FAR FAR shorter than the *3 YEARS* that the last revamp took (also for 
> KDE 2) or the ~2 years (iirc?) that 3.0 took. we want sometihng more like 3.0, 
> which took under a year. but that will only work if, like 3.0, we keep the 
> scope manageable and people work together.

KDE SC 4.8 is the next feature release, so pretending you aren't
skipping releases is just that.  So far the only example we have of
desynchronizing KDE module release schedules is with kdepim.  That
experience does not encourage me.  I don't think the choices are no
features at all in 4.x or having it take forever.  It can be done in a
way that lets people worrying about the near term get their work in a
timely manner without impacting people who are focused on the long term
vision.

>>>> 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
> 
> their work is welcome in frameworks. they merge it there (two people have now 
> done this that i know of, off hand) and ipso facto they are now working on 
> frameworks. great :)
> 
>> are interested in Frameworks, they're probably doing it already.
> 
> no, they aren't. i know this because the number of people who have asked me 
> how to do so outnumber the people working on it. we have not done a good 
> enough job of documenting goals, timelines and open tasks. i will be helping 
> to address this issue later this month at the irc meeting that was already 
> posted.
> 
>> 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.
> 
> the best way to "deal with it" is not to consider it a fork of kdelibs but the 
> next version of kdelibs (that's what it is) and help out with it :)
> 
> another way of putting is: please don't fighting your own teammates (the ones, 
> in this case, who have done the majority of kdelibs work in the last few 
> years), but join then.

I'd be interested if I could, but learning C++ didn't make it to the top
of the TODO yet.  I'm mostly interested in understanding how to
distribute things in a functional, reliable, supportable way for all of
4.x until the next generation is ready (then I'll probably be figuring
out the same for it.

I get that what you're doing makes complete sense from your perspective.

Scott K