Request: remove libkactivites from kdelibs (in experimental/)

[Kevin Kofler]

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

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

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

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
> contributors

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

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

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

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

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

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
>> libraries/frameworks.
> 
> 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 
for:
* 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:
> 
> https://git.reviewboard.kde.org/r/102291/

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 
helped anyway.

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

        Kevin Kofler