2012/1/31 George Kiagiadakis <[email protected]>: > On Tue, Jan 31, 2012 at 3:36 AM, Dario Freddi <[email protected]> wrote: >> 2012/1/30 David Edmundson <[email protected]>: >>> 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.
+1 > > 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. agreed all over. We should probably have a plan for that as well, today I'm trying to find out if upstream has any plan. Will you be at FOSDEM to discuss that, btw? > > Regards, > George > _______________________________________________ > KDE-Telepathy mailing list > [email protected] > https://mail.kde.org/mailman/listinfo/kde-telepathy _______________________________________________ KDE-Telepathy mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-telepathy
