Request: remove libkactivites from kdelibs (in experimental/)
Aaron J. Seigo
aseigo at kde.org
Fri Nov 11 08:45:05 GMT 2011
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
> 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)
> 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
> 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:
"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...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel