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

[Scott Kitterman]

On 11/17/2011 04:05 AM, Thomas Zander wrote:
> On Thursday 17 November 2011 00.14.23 Scott Kitterman wrote:
>>> 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
> 
>> I'd be interested if I could, but learning C++ didn't make it to the topof
>> the TODO yet.  I'm mostly interested in understanding how todistribute
>> things in a functional, reliable, supportable way for all of4.x until the
>> next generation is ready (then I'll probably be figuringout the same for it.
> 
> If there is one thing to take away from the many emails, and especially Aarons 
> excellent guidance towards the common thinking of the people doing the work, 
> then its to not wait until Frameworks is ready.
> 
> The Qt5 and kdelibs -> frameworks transitions are much much less intrusive for 
> apps than the Qt4 one and while it may take a little while to get the first 
> stable frameworks vesion out, you can focus on frameworks already as the "next 
> version".
> 
> I'm not sure why Scott is so focussed on the 4.x kdelibs and what lead to the 
> conclusion to ignore frameworks until its ready.
> So I'm just saying that you should consider refocussing that attention.
> 
> If you have a feature you would love to get into the common libs, you can 
> still do what we have done for the last 10 years in KDE.
>  *  You first develop it in your own application, write the unit tests, you 
> then stabilize it and you get more than one app to use it.
>  * Then you get library reviews and you pick a target library to push it into.  
> In this case this is frameworks; by default since 4.8 is closed.
> 
> I'm unsure why thats an issue for anyone. Its not a huge wait, and it 
> guarentees that your code will be in KDE for many years to come. On the other 
> hand focussing on kdelibs which is essentially a stable branch now, will mean 
> your code will die when apps switch to frameworks.
> 
> Bottom line, I think this thread has too many talk and too little people 
> volunteering for doing the work. And to be honest, I am not in a position to 
> put time into this either. My €0.02 is that Aaron made clear the enormous 
> amout of work (man-years!) and dedication it takes to do what Scott asked the 
> kdelibs developers to do.
> And I'm still not seeing anyone put in the in comparison tiny fraction of time 
> of porting the auto-download plasma thing to frameworks.
> 
> Scott K wrote also;
>> I get that what you're doing makes complete sense from your perspective.
> 
> It also makes sense from the long term, the medium term and the KDE community 
> perspectives.
> The short term you have to talk to the maintainer of the application you are 
> targetting; but thats obviously off topic for this list.

I'm reasonably confident we are still talking past each other (I'm not
claiming any kind of bad intentions - I just don't think we are
communicating very well).  I'm convinced it wouldn't have been difficult
at all to allow limited feature additions to kdelibs 4.8 and still
wouldn't for 4.9 (since I assume we'll at least have that release before
we move to KDE Frameworks), but the people doing the work are equally
convinced that's not possible without side effects that make it not
worth doing.

It's clear this isn't a productive use of anyone's time, so I'll quit
digging now.

Scott K