Importing TpQtLogger into our repos

[George Kiagiadakis]

On Tue, Jan 31, 2012 at 3:36 AM, Dario Freddi <drf54321 at gmail.com> wrote:
> 2012/1/30 David Edmundson <david at davidedmundson.co.uk>:
>> I want to move TpQtLogger into the git repo because we /need/ to have
>> a tagged version (i.e 0.1) sooner than later, and upstream don't seem
>> to care when I poked them. Also I have at least one patch on the repo.
>>
>> Can we discuss what the repo name should be now, rather than having to
>> do any renaming in the future.
>>
>> I would go with:
>>  telepathy-qt-logger
>> but if it's in our repos maybe:
>>   ktp-logger-lib
>
> Fork in a different repo with the same name, try to merge changes back
> upstream when time comes. I'll take care of figuring out what can we
> do with upstream asap.
>

I agree with keeping the name, but also take into consideration the
port to tp-qt. So, the name should end up being "telepathy-logger-qt".
It should NOT be "telepathy-qt-logger" (as it originally started and
was renamed later), because it simply is not an extension of the
telepathy-qt dbus api bindings, it is bindings for the
telepathy-logger library, which has little to do with dbus and the
whole telepathy spec. I also disagree with any ktp naming, as this is
not really a part of kde-telepathy.

Regarding the API, I wouldn't consider it so stable. First of all, it
is based on QtGLib from QtGStreamer, which is not yet meant to be
public for other libraries. I never liked the fact that it was used in
tp-logger-qt, but that was the fastest solution back then. Soon (I
hope) QtGStreamer is going to move to the new GStreamer 0.11/1.0
series, which effectively means breaking API/ABI and with this
opportunity I am probably going to change a lot of things in QtGLib as
well to improve it. It is most likely that QtGLib-based bindings will
from now on be generated from gobject-introspection data, so when this
happens the whole tp-logger-qt library will have to be refactored. In
addition, tp-logger-qt is bound to the API of the underlying tp-logger
library, so whenever that library breaks API/ABI, tp-logger-qt also
has to do the same. Given this restriction, I believe the versioning
should follow tp-logger's versioning, like it is done with
QtGStreamer. So, keep 0.2 as major version and release 0.2.1, 0.2.2
and so on until tp-logger bumps its major version to 0.3, etc.

Regards,
George