[Kde-pim] SyncML meeting - conclusions

[Kevin Krammer]

On Friday, 2010-06-04, Sascha Peilicke wrote:

> > - GSoC and SyncEvolution
> > Dinesh agreed that he will continue working on the SyncEvolution backend.
> > Since he is just getting familiar with the code, we agreed that instead
> > of replicating things and starting a new interface, he would just code
> > an Akunambol backend, which can be shipped with akunambol when it's
> > ready, and that the users can choose and load at runtime.
> 
> That's not yours to decide and at the same time crap. There won't be such
> thing as an Akunambol backend. There will be a SyncEvo Akonadi backend as
> stated in the GSoC proposal. There's no such thing as 'replecating
> interfaces', there's a (mostly) well-defined mechanism to create new
> backends for SyncEvo, that what he's going to utilize. Patrick already
> promised to help on those little issues that happened to both Ravi and
> Dinesh. Maybe I should clarify things, I am the GSoC  mentor of Dinesh and
> the Seasons of KDE mentor for Ravi, so as far as I'm in those roles I want
> to be informed about such decisions.


I had to wait for the thread start mail to arrive on the list to comment on 
this (in order not to miss anything not quoted here), so here we go:

We need to make sure that all involved parties have the same interpretation of 
"Dinesh agreed that he will continue working on the SyncEvolution backend." 
and "he would just code an Akunambol backend"

Dinesh is of course free to do whatever he wants in his spare time, so if he 
decides to work on an Akunambol backend alongside his GSOC work on 
SyncEvolution intergration that's fine.

Whether it is OK to change plans in GSOC is totally up to Sascha and Dinesh 
agreeing on such a change.

My recommendation as a GSOC mentor of many years is to stick to the original 
plan unless new difficulties make it necessary to change the approach.
Any change will unavoidably require change of time line, mid term or end term 
evaluation deliverable, etc.

It might be worth the effort but that should be thoroughly discussed by 
student and mentor, because those are the two who ultimately have to agree.

For example last year I was mentoring the SyncML project Sascha was working on 
as the student and at some point we decided to give up on the idea of 
implementing a SyncML server because this was just not viable using the 
Funambol library.

Which was unfortunate because that is the more interesting role for the 
desktop use case, but there was simply no point in wasting time for this.

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20100604/1af37773/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/