Request: remove libkactivites from kdelibs (in experimental/)

[Alexander Neundorf]

On Friday 11 November 2011, Aaron J. Seigo wrote:
> hi Kevin,
> 
> first, let's back off from the unecessary rhetoric. for instance, i don't
> think calling people hypocrites is going to get anyone anywhere other than
> annoyed, upset and divided. i hope we can agree on that.
> 
> On Friday, November 11, 2011 04:58:09 Kevin Kofler wrote:
> > You cannot really FORCE volunteers to work on what you want them to work
> > on.
> 
> no, but we can decide to work together and coordinate instead of working
> against each other, particularly when we share the same final interests.
> note that your statement is the same as saying that as a volunteer i can
> then commit anything i want to your application / library, which is,
> obviously, not true. there are means of process control, particularly
> maintainership.
> 
> note that the decisions which i am simply repeating and asking people to
> respect were made this past summer in a meeting of some 30 libs
> contributors and then brought here to k-c-d for further discussion. to
> ignore would be disrespectful of the time honoured principles in KDE.


I'd prefer if there wouldn't be a separate mailing list for the frameworks 
effort, but if it would use k-c-d instead. IMO this _is_ kde core development.
This would make it more public (yes, it is completely public, but still a bit 
hidden if you didn't subscribe the frameworks list).
 
...
> this is the same argument people used for 3.4 and 3.5. it marred the early
> 4.x releases (along with a few other related issues). we can avoid
> repeating those mistakes by learning from them. now, 5 is not 4, and this
> also makes a difference as to why we should shift more focus to
> frameworks. why? well:
> 
> * Qt5 is not Qt4: it isn't a huge burdon to port things over. the code and
> API is essentially the same.
> 
> * we aren't going for "add lots of huge new functionality blocks" (e.g.
> solid, phonon, threadweaver, sonnet, etc. etc. etc.); this is a
> maintenance reorganization, an opportunity to merge functionality into Qt5

... and into CMake, which is making good progress btw. :-)

> (which has a definite time deadline, btw, which we need to meet or else we
> lose that opportunity entirely) and a chance to alter some behaviour in
> our code that is most appropriate for a major release (though some things
> of this nature could be done post 5.0 as well)

...also for our buildsystem :-)

Alex