Request: remove libkactivites from kdelibs (in experimental/)

[Aaron J. Seigo]

On Saturday, November 12, 2011 10:35:02 Kevin Kofler wrote:
> 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.

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.

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

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)

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

besides kde-core-devel, it was also blogged by a number of attendees, so 
planetkde.org readership was in the loop. there was a story on dot.kde.org, so 
dot.kde.org readership was in the loop. there's documentation on 
community.kde.org. 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.

> In particular, nobody asked us
> distro people for it: I don't recall any sort of notice about this issue to
> kde-packager.

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.

> Yet scheduling is definitely something which needs to be
> discussed with distro packagers.

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

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

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.

> 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

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

> my GSoC proposal, I didn't even THINK that there'd possibly be no kdelibs
> 4.8, 

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

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

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

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.

> I don't dispute that a maintainer is ALLOWED to do so,
> but that doesn't make it a good idea.

agreed ...

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

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.

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

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.

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

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.

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

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

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.

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

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

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

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.

> Yes, I realize that you need the new stuff for Plasma Active. But why is

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

> Plasma Active considered so important that the features it wants can get
> into 4.x,

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.

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

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

ah, you mean your patches which you will put into fedora's version of kdelibs 
>=4.8. there is nothing forcing you to do that; it's a choice fedora kde is 
making.

> > 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? ;-)

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

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

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.

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

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.

> In any case, I
> doubt doing that would have improved 4.0 any. (I also think 4.0 wasn't THAT
> bad.)

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

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? :)

> > we can avoid repeating those mistakes by learning from them.
> 
> For that, we first have to identify them. 

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

> My perception is that the main
> mistake in 4.0 was that too many things got rewritten or refactored.

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

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

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

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

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

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

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.

> 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

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)

> most definitely we should not add MORE delays!

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

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

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

> Do you think Plasma Desktop will be ported to KDE Frameworks 5.x in time
> for:
> * Fedora 17? (April-May 2012)

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

> * Fedora 18? (October-November 2012)

doubtful.

> * Fedora 19? (April-May 2013)
> * Fedora 20? (October-November 2013)

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

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

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 
>=4.8 so that frameworks development moves forward (as well as not be impeded 
by having to, with increasing difficulty, merge forward changes made in the 
4.x branches)

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

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.

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

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.

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

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.

> corollary: Whenever Plasma Desktop doesn't compile against Frameworks, I
> cannot actually do any runtime testing of my feature!).

unit tests ftw. :)

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

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.

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

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

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.

> 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

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

> 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

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.

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

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

> 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

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

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

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- 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: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20111114/9c99996c/attachment.sig>