Request: remove libkactivites from kdelibs (in experimental/)
kevin.kofler at chello.at
Sat Nov 12 09:35:02 GMT 2011
Aaron J. Seigo wrote:
> 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.
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
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.
> 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
> no, but we can decide to work together and coordinate instead of working
> against each other, particularly when we share the same final interests.
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).
> 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
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.)
> 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
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.
> and then brought here to k-c-d for further discussion.
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.)
> to ignore would be disrespectful of the time honoured principles in KDE.
No, it would simply be realizing you made a mistake!
>> Preventing them from working on what THEY want to work on will just lead
>> to them moving their work elsewhere, e.g.:
> 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)
Putting the work into frameworks (only) is obviously not a solution for code
we want to ship now.
>> * separate git repositories (which in fact is exactly what you are doing
>> with libkactivities!
> 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)
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!)
>> * distro patches (which you keep complaining about, yet it is exactly
>> what the "frozen master" debacle is leading to),
> can you point us to these patches so we can deal with them?
You know those patches very well, they're sitting in your ReviewBoard.
> 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
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.)
> at stake is kdelibs progressing and staying relevant in the coming years
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.
>> (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
> 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).
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.
> we can avoid repeating those mistakes by learning from them.
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.
> * Qt5 is not Qt4: it isn't a huge burdon to port things over. the code and
> API is essentially the same.
That also implies that forward-porting features developed against kdelibs
4.x shouldn't be all that hard.
> * 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).
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
> 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
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!
>> when we're just talking about the libraries/frameworks, let alone when we
>> actually consider applications and/or workspaces building on the new
> 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)
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?
>> 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.)
> when, then? after Qt 5 can no longer accept ABI changing merges?
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.
> and why not now?
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").
>> In addition, this situation might actually push some contributors NOT to
>> work with you on 5.0 material.
> we already have that situation, don't we?
All the worse.
>> 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.
> 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.
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.
> 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,
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).
> 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.
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 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!).
> please do not rewrite history. see my comment from 3 months ago on August
> 11 to your initial review request:
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).
> "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."
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.
> you were given a heads up not a month ago, but 3 months ago
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
> along with the offer of help to make that merge happen.
Merge into a branch I wasn't and still am not interested in, because it will
not be shippable in our Fedora 17 release.
More information about the kde-core-devel