0.8 and beyond

[Thomas Pfeiffer]

On 20.11.2013 00:00, David Edmundson wrote:
> (typical Dave sized email below. Sorry)
>
>
>   - Libkpeople is getting a rewrite that won't have any of the current problems.
>
>   Summary is:
>    - Instead of storing all data in Nepomuk, we store a simple mapping
> and sources provide data at runtime
>    - PIM seem happy with this.
>
>   Right now this is 90% feature compatiable with libkpeople0.1, Martin
> and I have ported all the KTp stuff. Branch name is kpeople2
> everywhere.
>
>   I don't want this to be a thing that Martin and Dave work on
> independant of the rest of the project and I would like more of you
> involved.
>
>   - Call UI
>
> detrout is working on QtGstreamer1.0. This is amazing work, I'd like
> everyone who wants to see an open KDE video service to help step up to
> work on that.
>
>   - Encryption.
>
>   We want to support this so we can become the default IM client in KDE
> SC from 5.0.
>   The best approach I think will be to use libOTR4.
>
>   In Kopete this is a plugin, whilst we have a plugin system in KTp,
> ours has to be flexible enough to support the plasmoid and active -
> which can't do the low level widget interaction needed for OTR.
>
>   The Kopete code is basically:
>    - some KActions in the chat kpart (see below!)
>    - A singleton
>    - some dialogs
>    - message handling.
>
> The message handling can fit quite well into our plugin system, the
> rest not so much. I think we may have to compile it linked in to the
> main chat-widget code, but I don't want to see spaghetti code spread
> over everywhere.
>
>   - KParts TextUI
>
> There is some ongoing work to move the text-ui to use KParts. It means
> we can embed chat in other apps, we can make that library private, as
> well as simplify the code a lot as each tab can keep track of it's own
> actions. I /think/ this is close to merging, but has a crash without a
> patched kdelibs.. it would be good if we can avoid that.
>
>   - QML Text UI
>
> Please see here:
> http://community.kde.org/KTp/Tasks/TextUIQML
>
> The auto-scroll in the chat plasmoid (and therefore this) is the
> biggest blocker.
> Also please read my review and approve it.. :)
>
>   - Singleton AccountManager/Factories
> This A big API change, which will tidy everything up.
> I always used to say we can't use a singleton AM because:
> 1) we don't want to fetch data for all contacts for all services
> 2) we don't want the same features for all channelFactories
> doing so would result in /massive/ dbus overhead
>
> [1] is fixed in GlobalContactManager which upgrades connections
> [2] we can fix by using different channel factories in the different
> client registrars.
>
> If none of that means anything to you; just ignore this sentence.  :)
>
> --- Timelines
>
> I am currently thinking of merging kpeople2 code now-ish, entering a
> beta freeze, and releasing 0.8 soon after (i.e mid December). I know
> that doesn't leave a lot of time for other new features, but I think
> it's worth fixing this metacontact stuff ASAP. We can always release
> 0.9 soon after.
>
> I want your input on this; I don't want to dictate the project.

The general direction (at least those parts of it I understand ;) ) 
absolutely makes sense to me.
As for the timeline: It makes sense to me to get the kpeople2 version 
out soon, but since I care a lot about "version numbering psychology", 
I'm not sure if we should call it 0.8. Up to know, new 0.X releases of 
KTp usually contained at least some new user-visible features.
Though the kpeople2 merge is a big deal from the technical side, for 
users it will mostly mean fixed problems (not that this isn't 
important!) rather than new features, right?
Therefore I'm thinking that maybe it should be called 0.7.5 or 
something, as in "The features of 0.7, but now they work much better".
Cheers,
Thomas