Request: remove libkactivites from kdelibs (in experimental/)

[Aaron J. Seigo]

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

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

> * maybe even an outright fork like Trinity (of KDE 3) or MATE (of GNOME 2).

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 

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

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

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

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

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

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

-- 
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/20111111/1fc2a7ee/attachment.sig>