Request: remove libkactivites from kdelibs (in experimental/)

Thomas Friedrichsmeier thomas.friedrichsmeier at
Mon Nov 14 09:35:16 GMT 2011


On Monday 14 November 2011, Aaron J. Seigo wrote:
> besides kde-core-devel, it was also blogged by a number of attendees, so 
> readership was in the loop. there was a story on,
> so readership was in the loop. there's documentation on
> hell, it even made it to slashdot (ok, that last one is
> NOT  a good test ;)
> so we most certainly did communicate. you didn't catch it, and i agree
> that  that sucks. but it is not because the communication didn't happen in
> all the most appropriate places. the only thing we could have done more
> for you is to track you down personally, and that's just not a realistic
> expectation.

to throw in my two cents: I don't think the problem is the _amount_ of 
communication. But personally, I'm dearly missing a _central_ place with a 
plain summary of the most important status information about kdelibs.

My main focus of development is on a KDE-based application, not kdelibs. But 
every once in a while, I find a bug in kdelibs, and I want to contribute a fix. 
And every once in a blue moon, I want to contribute a small feature. For such 
sporadic contributions, the ratio of time spent on producing a patch versus 
time spent on figuring out how to get the patch into kdelibs is not a good one. 
Back in the good old days, this basically meant reading up on any freezes in 
effect. With the move to git, and now with frameworks efforts, the complexity 
has increased, considerably.

All relevant information is available somewhere, but having to search through 
half a dozen places (,, kde-core-devel, kde-
cvs-announce, blogs, dot, ...) is downright painful. Esp., if some of those 
places are littered with outdated and misleading bits.

So, what I would love to see is _one_ short up-to-date page with just the most 
relevant info along the lines of:
- You want to contribute a bug fix with no API changes, and no string changes: 
Commit to branch X. Additionally, merging your commit into branch Y would 
[not] be helpful but/and is [not] necessary.
- You want to contribute a bug fix with no API changes, but changes in i18n 
strings: Please wait until MM.DD.YYYY
- You want to do X: Commit to branch Z
- For non-trivial patches, please get your code reviewed, first:
- Here are some links to current background information on plans and 
schedules: X, Y, Z, and here's a step-by-step guide on pushing patches to 
kdelibs with git.

Ideally, this page would be linked from , if that is possible. 
Ideally, also, git would point we to it, when my push fails for some reason.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <>

More information about the kde-core-devel mailing list