We should make a snapshot of telepathy-spec From The Future and get CMs (and MC) working with it. One CM (Haze?) had a 'next' branch but it might not still work.
Created attachment 85926 [details] [review] [tp-glib master] Update to spec 0.27.1 --- I just released that spec.
Created attachment 85927 [details] [review] [spec next] Snapshot 0.99.1 Replace the NEWS file with some porting notes. --- I moved NEWS (unmodified) to NEWS-0.x, created a new NEWS, and used "git format-patch -B" to express that as a deletion and re-creation of NEWS. Let's see how splinter copes with that...
Created attachment 85929 [details] [review] [tp-glib next] Update to telepathy-spec 0.99.1 --- This is after reverting the new Avatars spec and the TpAvatarsMixin for now - we'll put those back when we have some CMs ported. I plan to "release" this as telepathy-spec 0.99.1, so we have a fixed point to compile against.
(In reply to comment #3) > I plan to "release" this as telepathy-spec 0.99.1 er, telepathy-glib 0.99.1
Comment on attachment 85926 [details] [review] [tp-glib master] Update to spec 0.27.1 Review of attachment 85926 [details] [review]: ----------------------------------------------------------------- ++
Comment on attachment 85927 [details] [review] [spec next] Snapshot 0.99.1 Review of attachment 85927 [details] [review]: ----------------------------------------------------------------- ++ I think that's way enough change for a 1.0 :)
Comment on attachment 85929 [details] [review] [tp-glib next] Update to telepathy-spec 0.99.1 Review of attachment 85929 [details] [review]: ----------------------------------------------------------------- ++
I've released 0.99.1. Progress on CMs, etc.: Empathy [unclaimed] needs Farstream, Folks, Logger, deprecation-cleanness Farstream [unclaimed] needs Bug #69435 for manual tests? Folks [unclaimed] - Gabble [unclaimed] let's do the smaller ones first :-P Haze [smcv] I have a branch that compiles, but it fails tests Idle [unclaimed] - Logger [unclaimed] needs deprecation-cleanness MC [unclaimed] - Rakia [unclaimed] - Salut [xclaesse] in progress
I'll do Idle.
(In reply to comment #9) > I'll do Idle. Bug #69604 For the record, http://cgit.collabora.com/git/user/cassidy/telepathy-idle/tree/tests/twisted/constants.py?h=next should contain all the new constants changes. Best to re-use it accross all the components.
(In reply to comment #8) > Logger [unclaimed] needs deprecation-cleanness I'll do it: bug #69705
(In reply to comment #8) > Progress on CMs, etc.: Empathy [unclaimed] needs Farstream, Folks, Logger, deprecation-cleanness Farstream [cassidy] nearly done Folks [xclaesse?] in progress? Gabble [unclaimed] needs more tidying on master first Haze [-] up to 0.99.1 Idle [-] up to 0.99.1 Logger [cassidy] in progress MC [smcv] next to do Rakia [cassidy?] - Salut [xclaesse] Bug #69628, Bug #69629
(In reply to comment #12) > Folks [xclaesse?] in progress? Yes, I'm on it. But it makes me hate vala even more than before, if that was still possible :) > Salut [xclaesse] Bug #69628, Bug #69629 Done up to 0.99.1
Folks is waiting for review: https://bugzilla.gnome.org/show_bug.cgi?id=708871
I released 0.99.2 to fix local_xmpp vs. local-xmpp. Haze, Idle, Salut are up to date with that, so I tagged a 0.99.2 version of each of those too.
Empathy [xclaesse] in progress https://bugzilla.gnome.org/show_bug.cgi?id=709318 Farstream [cassidy] up to 0.99.2 Folks [xclaesse] up to 0.99.2 Gabble [unclaimed] needs more tidying on master first Haze [-] up to 0.99.2 Idle [-] up to 0.99.2 Logger [cassidy] up to 0.99.2 MC [smcv] next to do Rakia [cassidy] up to 0.99.2 Salut [xclaesse] up to 0.99.2
Looks like we're nearly done. Treating "updated to 0.99.2" as idle, we have: Empathy [xclaesse] in progress https://bugzilla.gnome.org/show_bug.cgi?id=709318 Farstream [-] up to 0.99.2 Folks [-] up to 0.99.2 Gabble [cassidy] tidying up master first Haze [-] up to 0.99.2 Idle [-] up to 0.99.2 Logger [-] up to 0.99.2 MC [-] up to 0.99.2 Rakia [-] up to 0.99.2 Salut [-] up to 0.99.2 Could someone please release Logger 0.99.2, Tp-Farstream 0.99.2 and MC 5.99.2, so that we have a stationary target for Empathy? Some possible next things, after Gabble and Empathy are ready and tagged (next-0.99.2 or something, in Empathy's case): - move stuff from /usr/share/telepathy to /usr/share/telepathy-1 - decide whether the avatar cache can be shared between Telepathy 0 and 1 (I think it can) - decide whether Logger logs can be shared between Telepathy 0 and 1 (I think the Logger uses its bus name as a mutex, so we might need it to write in a new directory, and do read-only access to the v0 logs? Or we could make it take the old bus name but not implement any objects) - make MC use a different file for its crash-recovery state dump - make MC store accounts in $XDG_DATA_DIRS/telepathy-1, potentially with a "once only" migration of old accounts from $XDG_DATA_DIRS/telepathy and ~/.missioncontrol (leave a flag file in $XDG_DATA_DIRS - make sure all docs, etc. are parallel-installable - rename Telepathy-1.gir to Telepathy1-1.gir? (ask g-i people whether this is desirable?) - make MC install mc6-tool (or maybe rename it to telepathy-account) and mc6-wait-for-name - re-namespace from im.telepathy1 to im.telepathy.v1 so we're using a namespace we actually control (we don't own telepathy1.im) - squash Contacts and Requests into Connection - make NewChannels, HandleChannels etc. singular - bring all actually-implemented extension interfaces (except for the OLPC ones and maybe Gabble's decloak) into telepathy-spec, and from there into telepathy-glib - remove all unimplemented interfaces, we can put them back later - revisit the design of the Avatars interface and mixin: I would like the mixin to be a "view" of CM data, like I did for Names, rather than storing much (any?) of its own data - revisit the design of the Names interface and mixin
(In reply to comment #17) > - revisit the design of the Avatars interface and mixin: > I would like the mixin to be a "view" of CM data, > like I did for Names, rather than storing much (any?) of > its own data > > - revisit the design of the Names interface and mixin These are much lower-priority, and I don't consider them to be 1.0 blockers. Another useful thing would be to ask the OLPC/Sugar people whether they still need those interfaces; if not, delete them.
(In reply to comment #16) > Gabble [unclaimed] needs more tidying on master first bug #70078 and bug #70077
(In reply to comment #18) > Another useful thing would be to ask the OLPC/Sugar people whether they > still need those interfaces; if not, delete them. My plan was to remove them in next. If/when OLPC people wants to switch to TP 1.0 they'll just have to re-implement them, maybe using sidecars?
(In reply to comment #20) > (In reply to comment #18) > > Another useful thing would be to ask the OLPC/Sugar people whether they > > still need those interfaces; if not, delete them. > > My plan was to remove them in next. If/when OLPC people wants to switch to > TP 1.0 they'll just have to re-implement them, maybe using sidecars? Reasonable.
(In reply to comment #17) > - make MC store accounts in $XDG_DATA_DIRS/telepathy-1, > potentially with a "once only" migration of old accounts from > $XDG_DATA_DIRS/telepathy and ~/.missioncontrol (leave a flag > file in $XDG_DATA_DIRS We should also update accounts.cfg to update to new protocol names (link-local -> link_local).
(In reply to comment #22) > > potentially with a "once only" migration of old accounts from > > $XDG_DATA_DIRS/telepathy and ~/.missioncontrol (leave a flag > > file in $XDG_DATA_DIRS > > We should also update accounts.cfg to update to new protocol names > (link-local -> link_local). Right, and any other incompatible changes (e.g. if we rename the 'account' parameter to 'username', or finally change tp-rakia's internal name from sofiasip to rakia). My proposal at the moment is: * first: make MC use an entirely separate, parallel set of accounts in a new location (telepathy-1) * then, and only then: add a migration step: during startup, if you have no accounts, and the migration has never been done, migrate old accounts from their various possible locations (with any conversion that's needed) and set the "I have migrated" flag)
(In reply to comment #23) > * first: make MC use an entirely separate, parallel set of accounts in a new > location (telepathy-1) > > * then, and only then: add a migration step: during startup, if you have no > accounts, and the migration has never been done, migrate old accounts from > their various possible locations (with any conversion that's needed) and set > the "I have migrated" flag) Relatedly, I should probably update Bug #54874 and Bug #54875, which pre-date the removal of gnome-keyring support.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-spec/issues/140.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.