Releasing KDE Telepathy In May

[David Edmundson]

With nwoki making really cool progress on the presence plasmoid the only
outstanding task is file transfer \o/.

With this in mind I want the following.
 - If there's any bug (not file transfer) and you think it's important make
sure it's both on bugzilla and blocking the "make a preview release of
telepathy" bug.

- Try and be in a pseudo-feature freeze and focus on fixing small UI issues.
If you want to do any big changes, ask the ML first.

- Review any strings (bits of text) used throughout the apps, we don't want
to change things /after/ it's been translated.

- Make sure everything all works nicely together with each other, look for
inconsistencies between our components. Sensible defualts on first run etc.
Fix anything if it comes up.

 - Start thinking of what we want to do for the 0.2 release.

We're still maybe 2-4 weeks away, depending on how file transfer goes. May
as well make the time to make the rest of it super awesome.

On Thu, May 12, 2011 at 10:13 PM, David Edmundson <
david at davidedmundson.co.uk> wrote:

>
>
> On Wed, May 11, 2011 at 6:03 PM, Daniele E. Domenichelli <
> daniele.domenichelli at gmail.com> wrote:
>
>> On 05/11/2011 06:09 PM, David Edmundson wrote:
>> > *270672: Channelhandler daemon for file transfers
>> > *
>> > Dr Danz started this, hit some issues which means we'll only get working
>> > support in Jabber. Also requires a change in TpQt4. We can't ship until
>> > this change is merged into TpQt4 and they make a release. This is
>> > probably going to be the biggest hold-up.
>> >
>> > Could we try and make sure any work gets pushed to somewhere on kde git.
>>
>> This is the blocking bug in TpQt4:
>>
>>   https <https://bugs.freedesktop.org/show_bug.cgi?id=37034>*://
>> bugs.freedesktop.org/show_bug.cgi?id=37034*
>>
>> I can work on that bug, but I require some feedback from TpQt4 developers.
>> oggis_, andrunko: ping ^ :D
>>
>>
>> Caught Andrunko on IRC:
>
> [22:01] <andrunko> d_ed, the approach seems ok, just add a new constructor
> and a setURI, etc as needed there and pass the info when requesting the FT
> channels
> [22:01] <andrunko> and do not remove or deprecate current ones
> [22:04] <andrunko> d_ed, also obviously add a FT::uri() accessor, so
> handlers can get the uri passed
>
> As far as I understand it that's exactly what we wanted to hear (options
> 1&2 of your bug report), but they're not allowing any changes which break
> binary computability (understandably).
>
>>
>> Moreover the only connection managers that support the URI property at
>> the moment seem to be gabble and salut therefore, file transfer will be
>> supported only by those connection managers (unless we add some sort of
>> ugly hack).
>>
>>
>>
>> Most of the handler is already written, therefore I believe that if
>> TpQt4 bug is resolved we can ship it with the first release.
>>
>> By the way, as discussed on irc, I'm implementing it as a one-shot file
>> transfer handler (no daemon), therefore as soon as the channel is
>> received it will unregister from D-Bus and start the file transfer and
>> exit as soon as it finishes.
>> If a new file transfer channel is received, a new instance of the file
>> transfer handler will be started by MC.
>>
>> I believe that this is the best way to do it because:
>>
>> 1) A crash in one process won't kill all the other file transfers.
>> 2) There is no daemon running all the time and no need to check if it
>>   is possible to exit or if there are more transfers running.
>> 3) There shouldn't be racing condition with handler exiting/new file
>>   transfers channel sent by MC (I'm not sure if there could be a
>>   racing condition with handler unregistering/new file transfer
>>   channel sent by MC).
>>
>> If someone believes that this is wrong or has anything to tell about
>> this issue, please speak now... :D
>>
>>
>> > *270673: Support FileTransfer channel types  [ in approver]
>> > *
>> > I've not heard of any work on this. Probably waiting on the
>> > channelhandler. I think it's pretty trivial though.
>>
>> I started writing that, and I believe that also George K. started, but
>> the main issue for this is that popup notifications can be hidden by the
>> user...
>>
>>
>>
>> Cheers,
>>  Daniele
>> _______________________________________________
>> KDE-Telepathy mailing list
>> KDE-Telepathy at kde.org
>> https://mail.kde.org/mailman/listinfo/kde-telepathy
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-telepathy/attachments/20110525/28688186/attachment.htm