Request: remove libkactivites from kdelibs (in experimental/)

hi ..

we currently have libkactivities in kdelibs/experimental. due to upcoming
changs and frameworks 5 development, it has been moved into its own git
repository: kactivities.

i would like to request approval to remove it from kdelibs/experimental and
make the kactivities repository a dependency for kde-workspace.

the benefits:

* libkworkspace drops 4 classes (essentially halfing it in size)
* we have one place for libkactivities so people don't continue to get

the drawbacks:

* a new module required for building kde-workspace

note that this module is already a dependency for the plasma-mobile


Re: Request: remove libkactivites from kdelibs (in experimental/

By Aaron J. Seigo at 11/09/2011 - 10:20

On Friday, November 4, 2011 23:05:28 Aaron J. Seigo wrote:
unless there are any further objections, here is what i plan to do after the
release of 4.7.4 on December 6 (so as not to disrupt 4.7 releases):


in KDE/4.7 branch:

* remove the contents of kdelibs/experimental/libkactivities
* put a README in its place stating what happend so people can easily know
what to do now that it is gone

in frameworks branch:

* merge those changes, then delete the libkactivities directory altogether in
that branch


* merge my libkactivities branch into master

Re: Request: remove libkactivites from kdelibs (in experimental/

By Sebastian =?utf... at 11/07/2011 - 11:48

On Friday, November 04, 2011 23:05:28 Aaron J. Seigo wrote:
If we can recreate the tarballs as we used to, and Dirk indicated we can, then
I think this is a good solution to this headaching problem. We promised
packagers not to break up tarball layouts before Frameworks 5 any further, but
we can split up repos as long as we keep reassembling them for releases, which
is already the case for kdegraphics, for example.


Re: Request: remove libkactivites from kdelibs (in experimental/

By Rex Dieter at 11/07/2011 - 11:35

On 11/04/2011 05:05 PM, Aaron J. Seigo wrote:
+1, ok with me...

-- rex

Re: Request: remove libkactivites from kdelibs (in experimental/

By Allen Winter at 11/06/2011 - 11:29

On Friday 04 November 2011 6:05:28 PM Aaron J. Seigo wrote:

Re: Request: remove libkactivites from kdelibs (in experimental/

By Aaron J. Seigo at 11/07/2011 - 11:18

On Sunday, November 6, 2011 10:29:56 Allen Winter wrote:
KDE/4.7 and master are currently the same thing. so i'm requesting removal
from both, essentially.

Re: Re: Request: remove libkactivites from kdelibs (in experimen

By Albert Astals Cid at 11/07/2011 - 11:35

A Dilluns, 7 de novembre de 2011, Aaron J. Seigo vàreu escriure:
I can see a problem with the next 4.7.x release then :-/ I mean i'm all for
dropiing killing changing experimental libs, but not between 4.7.3 and 4.7.4

Maybe we should really resurrect the existence of a master 4.8?


Re: Request: remove libkactivites from kdelibs (in experimental/

By Aaron J. Seigo at 11/07/2011 - 13:07

On Monday, November 7, 2011 16:35:57 Albert Astals Cid wrote:
assuming 'business as usual' and once 4.8.0 is out we do not do a 4.7.5 (or
whatever release) AFTER 4.8.0 is out, then i'm just fine with waiting until
then. i would still like to do it in the "stable" branch of kdelibs rather
than open up master due to this as this should not take focus off of

unecessary imho, and runs the extreme danger of repeating the 3->4 debacle
with kdelibs where people just keep working on the stable release and don't
care enough for the next important release of libs.

we've already solved one set of issues by de-coupling workspace and apps from
the libs development, and i'd like to see the other issue of "ah well, it's
more useful (short term) to work on stable than the next major release" also
be addressed. we can only do this if we do not concentrate, or allow for work
to concentrate on, kdelibs stable but instead push ourselves towards

i understand the temptation, but i don't like what the outcome will almost
certainly be (indefinite delay of frameworks 5). let's learn from our past :)

Re: Request: remove libkactivites from kdelibs (in experimental/

By Kevin Kofler at 11/10/2011 - 23:58

You cannot really FORCE volunteers to work on what you want them to work on.
Preventing them from working on what THEY want to work on will just lead to
them moving their work elsewhere, e.g.:

* separate git repositories (which in fact is exactly what you are doing
with libkactivities! Talk about hypocrisy…),

* distro patches (which you keep complaining about, yet it is exactly what
the "frozen master" debacle is leading to),

* maybe even an outright fork like Trinity (of KDE 3) or MATE (of GNOME 2).
(But don't get me wrong, I'm NOT interested in keeping 4.x alive for ages,
I'm just interested in 4.x NOW because 5.0 isn't anywhere near ready, even
when we're just talking about the libraries/frameworks, let alone when we
actually consider applications and/or workspaces building on the new
libraries/frameworks. And I believe that most, if not all, people interested
in 4.x work right now are in that boat, I doubt 4.x is going to suscite
anywhere near the amount of long-term nostalgia 3.x did. We WILL eventually
work on 5.x. Just not NOW.)

In addition, this situation might actually push some contributors NOT to
work with you on 5.0 material. I can tell you that your refusal to get my
libplasma PackageKit work into 4.8 definitely did demotivate me from doing
any work on the 5.0 version. So you achieve exactly the opposite of what
you're trying to achieve.

That said, considering the 4.8 release schedule, it is now really too late
to reopen kdelibs 4.8 for feature development anyway. :-( It should have
been done when I originally asked for it a month ago (or even better, it
should never have been closed down in the first place!).

Kevin Kofler

Re: Request: remove libkactivites from kdelibs (in experimental/

By Aaron J. Seigo at 11/11/2011 - 04:45

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

well, that's exactly what i hope will happen. i hope they will movetheir work
into frameworks (either the branch if working on existing code or a git
repository that will become part of frameworks)

yes, because that is the shape the frameworks will take: seperate repositories
(easily fetched and built all at once, however, so no loss in "build it all" /
"work on it all" efficiencies). the reason libkactivities is now in its own
repository, along with its runtime requirements i might add, is to fall in
line with what the frameworks plan is (not all of which i personally agreed to
at first, btw .. life and big projects are full of being able to work with
others, including at times agreeing with the group of skilled, intelligent
people who have the same interests and goals as you do)

can you point us to these patches so we can deal with them?

it's a possibility. we could also choose to work together towards commonly
beneficial aims. i suppose it is up to us to decide whether it is more
important to work on the future of kdelibs together (following the team-
generated decisions) or to put new features into kdelibs for the 4.8 release.

at stake is kdelibs progressing and staying relevant in the coming years or

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

this means we have a very reachable goal (not years of work during which time
kdelibs 4.x will stagnate to death) and we have deadlines we're working
against (qt 5 ABI change window).

but it only happens if we focus on frameworks instead of kdelibs 4.x. bug
fixes are still fine. and we'll all live just fine without new features in
kdelibs for a couple releases. we have done so in the past, we will do so
again in the future. applications have all sorts of features missing and

do you know what that work will entail, or are is this just guessing and
supposition on your part? because it's not going to be as big as one might
think due to the SC goals. (plasma workspaces will have some work involved as
libplasma2 is undergoing some important changes due to QtQuick2)

when, then? after Qt 5 can no longer accept ABI changing merges? and why not
now? now is as good a time as any. using your reasoning, we can delay it
continuously .. at some point "not NOW" has to become "NOW" and we decided in
summer, which gave everyone LOTS of lead time on this, that "NOW" is indeed

we already have that situation, don't we?

i'm sorry you reacted that way. more productive might be to consider that as
your work was indeed reviewed, accepted and welcomed that having it debut in
frameworks 5 is a great thing. focus on the development and progress rather
than the negatives in the tradeoffs. there are ALWAYS tradeoffs, such as: "if
we decide to make this a '4.8 or else i quit!' power struggle and we refuse to
work together on frameworks 5, then we end up missing the Qt5 merge
opportunities, we'll lose opportunities to have our libraries used in other
Qt5 aps and efforts in the mobile area will be utterly fucked." there are
always tradeoffs. let's examine which are best to take and then move in that
direction without fear and with each other's support.

please do not rewrite history. see my comment from 3 months ago on August 11
to your initial review request:

<a href="" title=""></a>

"this work needs to shift to being written against the frameworks branch, and
then only after libplasma2 has been merged into it. note that in libplasma2,
there is no PackageMetadata class and the install package routine has moved
into PackageStructure as well."

you were given a heads up not a month ago, but 3 months ago, along with the
offer of help to make that merge happen.

Re: Request: remove libkactivites from kdelibs (in experimental/

By Kevin Kofler at 11/12/2011 - 05:35

Aaron J. Seigo wrote:
Unfortunately, it's the decision by some kdelibs developers including you to
stop everyone from working on kdelibs 4.x which is annoying, upsetting and
dividing people.

I don't want to offend you, but to make you realize this fact.

I am sorry if I come off as rude, it's really not my intention, but you have
to realize that I'm really frustrated by this situation.

Working together goes both ways, you also have to listen to our needs.
Nobody who doesn't read kde-core-devel daily and who didn't happen to be at
the in-person meeting you discussed this in was even aware of your post-4.7
plans, let alone asked for their opinion. In particular, nobody asked us
distro people for it: I don't recall any sort of notice about this issue to
kde-packager. Yet scheduling is definitely something which needs to be
discussed with distro packagers.

The need in my case is that we are going to ship my feature in Fedora 17
(This is not negotiable. It's already a release later than I had initially
hoped for, but at least in Fedora, missing a freeze window only delays you
for 6 months. I really miss the time where the same thing was true for all
the KDE SC modules. Sadly, judging from the kdepim fiasco first and now
this, it looks like Shuttleworth's lecture on how important predictable
periodic releases are for us distributions already got forgotten!) and that
IMHO it would have been better for everyone if it had been upstream by then.
There is obviously no way we can ship a Plasma based on libplasma from
Frameworks in Fedora 17, so 4.8 was and is the target. And when I submitted
my GSoC proposal, I didn't even THINK that there'd possibly be no kdelibs
4.8, or one with no new features allowed. In fact I only heard of this after
my patches to PackageKit and Apper were all already finished and applied
upstream (which proved to be very straightforward, unlike libplasma where I
hit a brick wall).

Sorry, but for me, keeping other people from doing their work is a sign of
bad maintainership. I don't dispute that a maintainer is ALLOWED to do so,
but that doesn't make it a good idea. The fact that this topic comes up
again and again (see e.g. today's threads about ksecretsservice) proves that
several people have a concrete need for doing work on kdelibs 4.x. Instead,
they're forced to work around you (plural "you"!) when you could easily
allow them to work WITH you. (Again, working together goes both ways,
closing down the branch people want to commit to is NOT working WITH them.)

In-person meetings (a.k.a. the infamous "watercooler discussions") are about
the worst possible place to take decisions in a global community project
with many volunteer (and thus necessarily part-time) contributors.

That's a more appropriate forum, but why hasn't anybody notified e.g.
kde-packager? And even then, there will always be people who missed the
discussion, which is another reason why reconsidering decisions based on new
evidence is sometimes needed.

I think the sample of developers included in your discussions suffered from
heavy selection bias, as (for various reasons) those people interested in
4.x work aren't the ones who go to your long-term planning meetings nor the
ones who watch kde-core-devel daily. (I wasn't following it at all when this
was initially discussed.)

No, it would simply be realizing you made a mistake!

Putting the work into frameworks (only) is obviously not a solution for code
we want to ship now.

Yet your libkactivities repository targets (also) 4.x, and you're sneaking
it in as a dependency of kde-workspace 4.8, as a result bypassing the "no
new kdelibs features for 4.8" policy on a technicality, and leaving us
packagers to deal with the resulting chaos (2 versions of libkactivities for

Yes, I realize that you need the new stuff for Plasma Active. But why is
Plasma Active considered so important that the features it wants can get
into 4.x, but the not the traditional GNU/Linux distributions which have
thousands of times as many users? (You can dispute the usefulness of MY
feature (I think it's important, but I'm biased, obviously), but what about
the KSecretsService work? That's cross-desktop interoperability work we
distro people are all waiting for!)

You know those patches very well, they're sitting in your ReviewBoard.

IMHO this is a false dichotomy. I don't see why we can't do both, especially
since the people involved are NOT the same people. (Otherwise we wouldn't
have this discussion in the first place.)

Or what? ;-)

I don't agree that continuing kdelibs 4.x work for a few additional releases
would make kdelibs not progress or become irrelevant in the coming years.

I also don't agree with this strong claim. I can't see any evidence to
support it. The issues with the early 4.x releases were due to the sheer
amount of changes, which as you say should not be an issue for 5.x.

Plus, the issues with the early 4.x releases are one of the things which
made continued 3.5 support necessary and very welcome! But even if 4.0 had
been perfect, stopping kdelibs 3.x feature development back when 4.0
development got initially STARTED would have hurt 3.5 a lot. In any case, I
doubt doing that would have improved 4.0 any. (I also think 4.0 wasn't THAT

I also need to remind you that (as I already wrote once) libraries have a
much longer shelf life than the rest of the SC: We shipped 4.0 in Fedora 9,
but most of our applications were still kdelibs3-based and benefited from
the kdelibs3 development which was still done at the time! The kdelibs3
improvements also improved our 4.0-based distribution release and thus the
public's perception of 4.0. And we still ship kdelibs3 now.

For that, we first have to identify them. My perception is that the main
mistake in 4.0 was that too many things got rewritten or refactored.

That also implies that forward-porting features developed against kdelibs
4.x shouldn't be all that hard.

Merging functionality usually means adding NEW API/ABI, not changing
existing one, so it should be possible in later 5.x releases' feature
windows as well, this doesn't necessarily have to happen in the ABI change

I think we're already very slow at delivering features to our users (it can
take up to a year if the timing is unfortunate), having a couple release
series (for me, a "release" is e.g. 4.7.3, 4.7 is a "release series") with
no new features at all is going to make this unbearable.

As I already stated back in the early 4.x era, I actually think we need to
find ways to get popular features to our users faster, e.g. by allowing
uninvasive features into point releases as was done in the 3.5.x series. But
most definitely we should not add MORE delays!

Well, what is your ETA?

Do you think Plasma Desktop will be ported to KDE Frameworks 5.x in time
* Fedora 17? (April-May 2012)
* Fedora 18? (October-November 2012)
* Fedora 19? (April-May 2013)
* Fedora 20? (October-November 2013)
etc. (You get the pattern.)

Also, do you think the ETA will be more dependable than the one for 4.0
which kept getting pushed back again and again?

Well yes, after Qt 5 is actually in a state where it can be packaged, so we
can develop against a Qt 5 package rather than having to build all of Qt
from source to develop kdelibs. A framework with unstable ABI is very badly
suited for packaging.

Because doing the work now means that, in order to do any sort of testing on
it, I have to build everything from source (and on my own machine, because I
can only use the Fedora build system on stuff that is packaged): the
dependencies (including Qt 5 when you'll start requiring it, if you didn't
already), KDE Frameworks and Plasma Desktop (because Frameworks is not a
binary-compatible drop-in replacement for kdelibs 4.x, obviously, so I can't
test anything without also building a matching Plasma Desktop; corollary:
Whenever Plasma Desktop doesn't compile against Frameworks, I cannot
actually do any runtime testing of my feature!).

If, on the other hand, I wait until we decide what Fedora n will carry the
new Plasma Desktop and import snapshots or prereleases of it after Fedora
n-1 branches, I only have to add a patch to the Rawhide package, send it to
Koji until it builds, then runtime-test it using the nightly live CDs Fedora
composes automatically, which is much less resource-intensive on my end, and
the feature will still end up in the same Fedora release.

So please realize that the timing of doing the work significantly affects
the workload involved for me.

By the way, the way I tested the patches against 4.x is that I applied them
to a kdelibs 4.6.5 (!) package, built it and fixed the patches until it
compiled, then upgraded my notebook's system kdelibs to the patched version.
Obviously, this way of working won't work for Frameworks (now). (That's one
reason why I did the work against 4.x.)

But anyway, whether I do the work for 5.0 now or not, that still leaves the
issue that I need it in 4.x as well for Fedora 17 (and 18 etc. up to "n-1").

All the worse.

Sure, it's going to be a great thing for Fedora because we will be able to
advertise the new feature months (years?) before you. If I really cared only
about Fedora as you're insinuating, I'd LOVE this. But actually, what I see
is that this situation is going to suck for everyone else, which is why I
fought again and again for getting my feature into 4.8. We have this nice
feature, it is all already implemented and ready, why can't we offer it to
our users? From a user's perspective, this makes no sense whatsoever.

Please don't misunderstand me, I'm not running away (yet ;-) ), I still do
want my feature in 5.x as well, this just dropped by several spots in my
(long!) priority list due to the way it was received (also because I think
that whether this gets into 5.x now or later won't actually change much in
practice: I'll still have to ship my patch against 4.x, and our users (and
the other distros' users, i.e. basically all users) will get the feature in
5.x even if it's ported later, considering that there is no release in the
immediate future anyway).

If you had said "make a version for 5.x and we'll accept it into 4.x as
well", that would have been a motivation to do the 5.x work (and I'd have
actually understood that requirement; feature regressions are something I
can't stand at all!). But doing it for 5.x ONLY is not of any practical
interest to me (yet).

What is there left to examine? You make it very clear that your decision was
already taken and is not negotiable.

I would have loved actually discussing the issue with you before the
decision was taken, but I wasn't asked! And now you're actually asking me to
move in YOUR direction, which is quite a different thing from "examin[ing]"
(together ("let's")) "which [tradeoffs] are best to take and then mov[ing]
in that direction without fear and with each other's support".

By the way, I also don't think that allowing applications to pick pieces of
kdelibs / KDE Frameworks à la carte (and otherwise be Qt-only) is a good way
to promote an integrated experience. I think that there should be one KDE
Framework rather than KDE Frameworks, and that Qt-only apps are part of the
problem, not the solution. (One way to get rid of them might be to merge a
fork of Qt into kdelibs (and actually link it into the same libraries, i.e.
merge the libraries rather than splitting them!), which would also allow
reducing code duplication by removing Q* classes which have a better K*
alternative, and which would make Qt-only applications be as foreign on KDE
Plasma as GTK+ apps, making it a less attractive option for developers.) I'm
also worried by the current "reduce dependencies" trend, which strikes me as
a euphemism for "reduce code reuse" and/or "reduce integration". I think
that everything depending on everything is/was a GOOD sign, it means we
reuse(d) code and we care(d) about integration and consistency. And finally,
I think the focus on the mobile platform hype at the expense of the
traditional desktop (desktop computer or notebook computer) is also a
worrying trend. But this is getting very much off topic.

That review request came only after I had already done the GSoC proposal and
the development on all the dependencies, with only the last, but crucial,
piece (in libplasma) missing, and in fact started to work on that piece as
well (since the review request was the first part of it).

So for one thing, I had (mis)taken that to mean that you want this to be
developed in frameworks FIRST, as opposed to ONLY in frameworks.

And besides, I had to develop the 4.x version anyway, because that's what we
will ship in Fedora 17. Which is another reason why I finished the work
against 4.x even though the rumors about the freeze started trickling out.

The "a month ago" refers to when I sent the thread to kde-core-devel. I
realize it was late, but I had hoped (in vain) that the decision would have
been obviously overturned, given how much it makes absolutely no sense to
me. Now I regret not having spoken up sooner, though I'm not sure it'd have
helped anyway.

Merge into a branch I wasn't and still am not interested in, because it will
not be shippable in our Fedora 17 release.

Kevin Kofler

Re: Request: remove libkactivites from kdelibs (in experimental/

By Aaron J. Seigo at 11/14/2011 - 00:40

On Saturday, November 12, 2011 10:35:02 Kevin Kofler wrote:
i understand you are frustrated. that is very clear :) i don't want you to be
frustrated. at the same time, your frustration is not a reason to jeopardize
kdelibs. my hope is that if we can communicate clearly why we are doing what
we are doing and when we are doing it, that frustration will be avoided.

we did a good amount of communication around this matter months ago. because
of your frustration (and the confusion of others added to that), i've taken to
redoubling efforts to get the planning better documented and yet another round
of communication done. honestly, i don't (in theory) have the time for that.
but it needs to be done because it matters, as you well know personally from
this experience.

but i, and the rest of us working on frameworks, remain committed to doing
what is best for kdelibs as well as the broader community of KDE developers
and users. we are not interested in short term thinking driven by frustrations
over the immediate.

we are. we're also listening the 10s of 1000s of other developers, KDE and Qt
alike. we're also listening to the few dozen who contribute to kdelibs
directly. the bulk of code written in kdelibs in the last couple of years was
represented in Randa. (inc, btw, people working on Secret Service; which, if
nothing else, shows that just because you are part of the discussions and
getting support does not mean things will work perfectly; and that's ok: we
can adapt and work on fixing things)

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.

seeing as we aren't disrupting the 6 month 4.x release cycle, it honestly did
not occur to me to ask distros how we should schedule the next unstable
version of KDE's libraries. i'm not sure how many other library developers ask
distros about their future releases, either, though. (meaning: i think you're
holding KDE to an unrealistically high standard here.)

now, if we were simply stopping 4.x releases altogether, that would be a
concern, yes. but we aren't. and we have been communicating broadly.

i did reach out to packagers, btw, as can be seen in my blog entries and
emails on the matter. and we did have at least one packager who attended
Randa. however, it seems i didn't send email to the kde-packagers mailing list
.. if that was a failing, i apologize.

even when we aren't stopping 4.x releases? not even delaying them?

we're still doing 6 month releases of 4.x code. features are still allowed and
encouraged in apps and workspaces. furthermore: to suggest that all features
started now will be in a release within the next 6 months defies all
experience: some features take longer.

even Mark Shuttleworth has written blog entries lamenting the problems with
sticking too tightly to 6 month dev cycles, and how sometimes you need some of
the code to have periodic longer cycles.

we're doing that for kdelibs in a very critical time ... all while continuing
4.x releases so users get new features in apps and workspaces, bug fixes in
the libraries, and distros have new things to work with.

i agree that this is a challenge when targetting development at one particular
downstream's release cycle instead of upstream's release cycle.

me neither. but somtimes things change. and your GSoC proposal was
undestandably not the ultimate deciding factor in the schedule for frameworks.
we knew there were tradeoffs. but they are tradeoffs with positive end

did you run up against PackageKit or Apper's devel cycles? had you tried to
merge them during one of their feature freezes, or new features to a stable
branch where new features were no longer being applied, do you think it would
have been different?

the "brick wall" you ran into is due to release coordination and planning. in
that same time period, dozens and dozens of patches (some much bigger than
yours) made it through review-board. take the recent libtaskmanager changes as
one example. (libtaskmanager is in kde-workspaces, and not slated to be part
of the frameworks 5.0) this isn't a problem with libplasma, it's a problem
with you not being able to respect the devel cycle of the project you are
contributing to. it happens.

you aren't being held from "doing your work". you are invited to do it in
frameworks. just as you are invited to do new work in master, rather than in
the stable branches of modules. i understand you think that features should be
able to land anytime in master.. and you know what -> i AGREE!

frameworks, btw, is going to bring with it a new git-enabled workflow that
allows features to be merged when ready into master at any time (without
screwing over translators or stable releases; read the proposal if you have
concerns about those things). to get there, which is where you want to be,
requires we do not take some path-of-least-resistence choices the short-term.
namely .. we focus on frameworks and freeze kdelibs 4.x for features.

agreed ...

aah, so when we do what you want, it's working with you. when you do want we
want, it's working against you. :) c'mon ...

look, putting features in KDE/4.7 means we, those of us pushing kdelibs to the
next important major milestone, have to "work around" those feature efforts by
increasingly heavy forward porting burdons and fewer eyes and fingers on the
frameworks code.

i've done some of this back-and-forth porting already and it is not easy (or
fun :) and it really does slow things down considerably. i've spent large
portions of a day handling just one set of merges, with no forward progress
because of the merging effort.

most of the people who attended Randa are volunteer (and necessarily part-
time) contributors. those of us who get to spend "all" our time on these
topics were the minority by far.

it's also well documented at this point that getting those volunteers (and
paid people, too) together face-to-face from time to time to work on this big
issues pays off hugely. that's why we do so many developer sprints and spend
so many of our financial resources on them.

because we are continuing to do 4.x releases. as such, what does kde-packagers
have to do with the stage at which frameworks is in? THAT said ... i did reach
out to packagers for the Randa meeting and tried very hard to get packagers
there. i was successful in doing so (e.g. Sune) but it was not easy.

i am trying very hard to accomodate of your input here. i've gone through git
logs due to issues you raise (see below for that...)

we do need to stay reality based: sometimes new evidence turns out to not be
concrete upon examination; other times it's evidence that has already been
considered. sometimes, new evidence will indeed by new and concrete, but it
takes more than just someone saying something for that to be the case. so ..
let's dig...

4.x work in apps and workspaces continues. those working focussed on libs
issues and concerned about the future of kdelibs/runtime need to be following
kde-core-devel. it's where cooridination happens. just as plasma coordination
happens on plasma-devel.

you don't need to follow k-c-d daily .. weekly is more than enough. in this
case, monthly, even.

i think we have a differing definitions of "we". i'm looking at the people who
are working on kdelibs and representing their collective voice (including,
btw, a few things that i don't/didn't personally agree with, but which i
accept as the group's decision, and having a basis on other people's good
reasoning ... )

first, there is no sneaking involved. second, that chaos would have existed
_anyways_ since it was in kdelibs/experimental where the API and ABI is
allowed to change. so:

a) kactivities is a separate and new library (having been in
kdelibs/experimental up till now)

b) libkactivities was not being used by kde-workspace. a copy (!) of the code
in libkworkspace was being used.

c) since kdelibs 4.x is feature frozen, we went for the frameworks approach.
because of the decoupling of libs devel cycles from apps and workspace, this
allows us to very nicely use this library. other new libraries can easily
enter the scene the same way.

feature adds to existing 4.x libraries are obviously a different story.

and Plasma Desktop, the half dozen or so components in kde-workspace that use
those classes and share-like-connect.

you're confusing kdelibs with workspaces and apps. there are no new features
being put into the kdelibs or kderuntime modules due to Plasma Active. in
fact, we caried some rather large patches so that Plasma Active specifically
did NOT interfere with release cycles (we butted, for instance, right into the
4.7 devel cycle at a very awkward moment for us.)

the kactivities situation is really no different than having a dependency on
some new 3rd party library.

i agree, and i think we're all aware that there is a tradeoff being made here
between getting kdelibs features to people in january and getting frameworks
to them sooner (with all the features and improvements it will bring).

ah, you mean your patches which you will put into fedora's version of kdelibs
we lose opportunities in the mobile space.
we lose opportunities to bring in more devs who see themselves as "qt devs"
only right now.
we lose the patience of some of our larger supporters who are seeing KDE as a
whole and KDE's libs as "less relevant" compared to other Qt based projects /
we lose the opportunity to get code pushed into Qt5, reducing duplication of
both code and effort between Qt and KDE libs.
we wait even longer for a well modularized kdelibs, something many of our own
app developers have been asking for.

none of the above is speculation. i know first hand of specific instances of
each of the above situations.

other issues were:

* continued effort going into 3.x libs, leaving 4.x efforts to languish. this
resulted in not only a 3.4 but also a 3.5. we probably had little choice since
at the time apps and workspace devel cycles were tied to library devel cycles.

* apps and desktop were coupled tightly to libs development, meaning we
couldn't let libs develop without killing apps and desktop progress. which we
ended up doing because of that coupling -> it tugged libs development to focus
on 3.x, and eventually it made apps and desktop devel halt / slow down
dramatically while 4.x libs got into some sort of shape (as we couldn't do
libs dev cycles separate from apps & workspaces at the time)

* Qt4 being hard to port to from Qt3 code bases

* a lack of clearly stated goals up front that covered kdelibs. so we ended up
with a variety of things (many of which have turned out quite nicely
eventually; some which didn't) going on all at once with very little clear and
coordinated direction. (note, btw, that plasma was nowhere near kdelibs at
this point in time; it was "merely" having devel hamstrung by Qt and kdelibs

the first two issues were very much due to a continued focus on 3.x. the Qt
issue was out of our hands, the lack of clear planning was not helped by the
lack of focus of 4.x.

the Qt issue is being addressed with and for us, and the rest we're trying to
do better this time around.

let's examine this claim. (subtitled: oh, how i love `git log` :)

from 3.5.8 to 3.5.9, there were (by my count) 22 bug fixes, 2 performance
improvements and 0 features added.

from 3.5.7 to 3.6.8 there were approx 75 commits fixing bugs, 1 that was
obviously performance related and 1 feature add.

from 3.5.6 to 3.5.7 was similar, but with 2 feature adds (and one feature
reverted it seems?) and the rest being bug fixes.

3.5.5 to 3.5.6 had ~4 new features, all of which but one seem to have been
done in the 4.x code first, with the one that wasn't being a modification to
allow kate 3.5.x to coexist better with kate from 4.x.

none of these features were large (in terms of code or individual importance).
all the big features during this time were going into the 4.x branch.
of the fixes, many were backported from the 4.x efforts. 3.5.x seems to have
done just fine.

3.5.1 seems to have been all bugfixes. i didn't bother looking at the rest as
it was already taking quite a bit of time.

note that i didn't count translations, documentation changes or trivial fixes
to code (e.g. compiler warning fixes).

as we're not stopping bug fixes in the KDE/4.7 branch (and really, why would
we?) and as most features do not appear in kdelibs but in the applications
themselves, your concern of stunting upcoming releases seems unfounded.

the features in the upcoming 4.8 releases that do not rely on kdelibs features
also seems to back that up.

it wasn't "bad", but it was very disruptive. worse: workspace and apps were
delayed and undeniably hurt by the way libs development was handled. (from Qt
through to kdelibs.)

bug fixes and performance improvements are still welcome in the KDE/4.7
branch. most features don't appear in kdelibs, but higher up in the
applications. we'll continue to ship 4.x feature updates of workspaces and
apps while frameworks goes through its devel cycle.

those three themes repeated often in this email.

of course, some features do appear in kdelibs (secret service, kactivities,
your package kit integration are all examples), and we want to get those
features (and the rest of frameworks' goals) out as soon as we can rather than
see frameworks delayed and delayed. (do you know how many features are already
in libplasma2 that we're having to wait on? :)

agreed. and we have worked on doing that already in the recent past.

agreed. and we're avoiding doing that. how?

* by not making introducing major new libraries a priority (though it can
happen in the natural flow of things) while we also make other significant
changes (e.g. the modularization)

* by decoupling the early lib work from workspaces and apps work so that we
don't end up with tons of "ripple effects" from the early days of the libs
moving around rolling into (and working against) the stable workspace/app
efforts. changes in the workspaces and apps will be allowed to happen at their
own pace.

* by a stated, documented focus on source compatibility

* by documenting before we got started what we wanted to achieve (to avoid
endless feature sprawl). we need to improve this documentation, and the irc
meeting we'll be holding near the end of this month will be a step in doing

no, because frameworks is changing structure and dependencies between
libraries ... which makes forward porting more difficult as time goes on.

agreed, some of the changes don't require changing API/ABI. but,
unfortunately, some do. we discovered this unfortunate fact during
examinations of when what we'd like to see merged. KUrl -> QUrl is a good
example of that. on the flip side, KIon -> QIcon is a good example of a "few
missing features in QIcon that can be added later". so there are examples of
both, but the API/ABI breakages require we get working now.

people have been doing ground work. people like (though not limited to) David
Faure and Thiago. people who, at least i, trust to get this stuff as near to
"right" as can be expected from a human :)

have you not noticed the feature additions in kdebase-apps, kde-workspaces,
kdeplasma-addons for 4.8.0? kdelibs is not where the bulk of features appear
in any given release.

the feature additions in 3.5.x did not all go smoothly, let's not forget. and
how many of those feature adds were in kdelibs, vs in the desktop or
applications? (for the desktop, it was almost exclusively in kdebase)

we're not. by working on libs first, separate from the workspaces and apps,
the workspaces and apps can add features while development continues.

even as frameworks development has started, i've overseen numerous feature
additions to the workspace modules. have you seen the 4.8 preview videos that
have started making their way on to youtube? they are quite nice and show
numerous features despite a freeze in kdelibs

from dolphin 2 to the more trivial (addmitedly :) picture of the day wallpaper
to Plasma Active One .. we're rolling out lots of features.

if we kept to the way we working in 3.x days, we'd be stalling all of that
work to focus people on 5.x code. instead, we're working on the frameworks
first without blocking features in apps and workspaces.

iow: less delays. as requested. :)

we want to release frameworks as soon after Qt5 as we can. how soon is yet to
be determined (largely based on focus that we can train on frameworks
development). that relies on the cooperation of libs developers, however.
we'll do our best to firm up timelines for frameworks at the meeting at the
end of the month, but we will remain focussed on 'when it is ready'.

that would require a time machine, wouldn't it? :)


possible. but we haven't committed to any dates for that yet.

that is PRECISELY the goal of the program you're pushing back against.

we have de-coupled library from workspace and app devel so we can get
libraries into early shape first while simultaneously continuing to do
workspace and app releases with new features; this allows consistent, timely
releases for users and downstreams while not holding up library development.

we are (trying) to focus libs devel on frameworks rather than feature adds for
you missed the point of my question. the question was not, "when do we move
the dependency of Qt in kdelibs from Qt4 to Qt5". the question was, "how long
do we have until we can no longer merge things from kdelibs into Qt5". we do
not yet require Qt5 for frameworks, and won't for a while yet.

fair enough; so when ever we make this break in development, it has to be when
you personally are not working on a new feature. i hope you appreciate how
unrealistic that requirement is on kdelibs development, when taken as a whole.

since it's in a library, and in this case very much does not rely in any way
on user interaction or UI outside of libplasma, it should be able to be unit
tested very easily. it shouldn't (and doesn't) require Plasma Desktop at all.

this, btw, is how i ended up adding the package signing to libplasma. (another
GSoC project that is only in frameworks.) with unit tests i could make sure
everything there worked as expected, and never once did i build any plasma
code outside of kdelibs againts it.

unit tests ftw. :)

everyone is aware of the workload changes involved. we're all affected by it.
we're trying to minimize that affect globally, which means there can be some
local pain here and there.

from a short term "give me everything now" perspective, yes, it doesn't make

from a product planning perspective that take the next several years into
consideration, it does.

i understand that there is gap between those two POV, and that we need to find
a way to reconcile them as much as possible.

what we need to keep in mind is that this is not a single instance of this
pattern. for you, maybe it is: you only want one feature (the one you've been
working on) in the 4.x branch(es).

for kdelibs, it's a scenario we are repeating over and over. "do it in
frameworks as well as in 4.x" is probably quite close to double the work (more
in the case of more trivial features); merging changes (feature improvements,
bug fixes, etc.) will become harder and harder as frameworks diverges more and
more to the point where merging will be "have git make a patch file, apply it
by hand to frameworks" and things will rapidly get messy to the point that
frameworks devel will be held up even more, something we can ill afford.

if this was the only feature ever to go into both frameworks and 4.x, that
might be something very different. but it isn't. there are a number of such
features. some are already in frameworks, btw.

so the difference between "playing this game just once" and "playing this game
many times in the next year" makes a big difference in the decision making.
and i understand you are on one side of that table and i'm on the other :)

there was an open call for the meeting in Randa, which was very well attended
by nearly 60 people, most of whom work on kdelibs. during and after the
meeting, the results from the meeting were posted here for discussion. no one
can be responsible for people missing the discussion if they weren't here to
have it.

if an app only needs, say, hardware awareness and get everything else it would
otherwise need through the platform plugin, the having Solid a la carte leads
to a more integrated experience.

the failure in thinking in the past has been that if everything is welded
together, then apps will use everything. yes, some will. many will, however,
just use nothing. we know this not by theory and philosophy, but by experience
and easily documented behaviour.

those who want to use everything still can and will even with a componentized
frameworks. the difference will be that those who want / need only _some_
functionality just might do so as well, leading to more, not fewer apps,
sharing code with KDE and being, as a result, more integrated with our user

there are still dependencies. they are, however:

* more thought out (is that dependency really required, or was it there "just
because"? does it actually add something to the library?)

* tiered: so there will be "only Qt as a dependency" libraries (we already
have those in kdelibs), libraries that depend on those (ditto), and yet other
libraries that depend on libraries-that-depend-on-qt-only libraries.

iow, there's more attention to intentional design than random sewing-of-

hth ... (from a very tired aseigo at nearly 6am)

Re: Request: remove libkactivites from kdelibs (in experimental/

By Thomas Friedric... at 11/14/2011 - 05:35


On Monday 14 November 2011, Aaron J. Seigo wrote:
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
<a href=";a=summary" title=";a=summary">;a=summary</a> , if that is possible.
Ideally, also, git would point we to it, when my push fails for some reason.


Re: Request: remove libkactivites from kdelibs (in experimental/

By Aaron J. Seigo at 11/14/2011 - 06:34

On Monday, November 14, 2011 10:35:16 Thomas Friedrichsmeier wrote:
the complexity will eventually subside. right now it's something like:

* until further notice, if it is a bug fix, put it into KDE/4.7 and it will
get merged forward into frameworks

* if it is a feature, do it in a branch off of frameworks and when it is
ready, it can be merged in

it is complex because we currently have to juggle between 4.x freezes,
frameworks progress and the evolving state of that effort in a branch. it's a
transition period that we all want to be as _short_ as possible so we can get
back to simple.

in future it will be:

* bug fixes can always be applied to the stable branch; these will get merged
into master.

* features can be opened at any time in a feature branch and merge into the
testing branch when they are ready for testing by your fellow developers. when
it is ready for merging, it'll get merged into master.

notice the lack of discussion there about freezes. all you'll need to know as
a casual contributor is where feature branches come off of and what the latest
stable branch is, and whether your addition is a bug fix or a feature.

for casual contributors, this should be very low-barrier-to-entry. you
shouldn't even need to consult the release schedule for things like feature
freezes :)

completely agreed.

that is one of the primary reasons we're getting together on irc later this
month. it is quite clear to everyone that this is sorely needed, and so we're
going to make this thing along with some other supporting information for
frameworks ...

Re: Request: remove libkactivites from kdelibs (in experimental/

By Alexander Neundorf at 11/11/2011 - 11:50

On Friday 11 November 2011, Aaron J. Seigo wrote:

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

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

...also for our buildsystem :-)


Re: Request: remove libkactivites from kdelibs (in experimental/

By Aaron J. Seigo at 11/11/2011 - 12:24

On Friday, November 11, 2011 16:50:00 Alexander Neundorf wrote:
you might be right. the concerns that were raised was that k-c-d has gotten
pretty noisy and at times the place where the proverbial peanut gallery comes
to hang out ;) i'm not sure a separate list was the best idea, however it the
signal-to-noise ratio was the motivation.

yes i've been sort-of-kind-of following that and its looking pretty promising
indeed! :) integrated automoc ftw...