[Kde-pim] Akonadi GroupDAV Resource
Marco Nelles
marco at maniatek.de
Fri Oct 23 14:21:53 BST 2009
Hej,
> is there are reason why this is developed in some random git repository
> instead of KDE's subversion?
Just because I've started development on a git rep on my server. No special
reason.
From my point of view it would be even great, if this little project could be
hosted in KDE's subversion.
So if this is simply possible, let's do it.
> Looking at the code I spotted some of the usual problems with unguarded
> return paths from retrieveX methods (ie. there is a retrievalDone() or
> cancelTask/deferTask call missing, causing the resource to hang in this
> cases). Similar in the itemAdded|Changed|Removed methods. I could have
> fixed that easily in the time it took me to write this mail, with the
> resource in KDE's repositories ;-)
Thanks, any kind of help is more than welcome!
Best regards,
Marco
Am Montag 19 Oktober 2009 16:04:01 schrieb Volker Krause:
> On Sunday 18 October 2009 18:33:44 Marco Nelles wrote:
> > I'm developing an Akonadi GroupDAV Resource.
>
> great :)
>
> > Feel free to download and try (released under the terms of GPL v3). It is
> > still under heavy development. If you're interested: Any suggestions are
> > welcome!
> >
> > http://opensource.maniatek.com/calgo
> >
> > or check out from here:
> >
> > git clone git://github.com/marcomania/Calgo.git
>
> is there are reason why this is developed in some random git repository
> instead of KDE's subversion? Sure, git has its adavantages, but the KDE
> infrastructure provides stuff like nightly builds and test-runs, static
> code analysis, translations into countless languages and most importantly
> review by the KDE PIM and wider KDE community. I can't track countless git
> repositories, but I read every commit affecting or using Akonadi in KDE's
> repository. I can fix minor issues when I see them, without having to
> figure out the patch submission procedures of the used git hosting
> service. That's not just a problem with your resource of course, rather a
> general worry of mine, caused by the recently increasing repository
> fragmentation.
>
> Looking at the code I spotted some of the usual problems with unguarded
> return paths from retrieveX methods (ie. there is a retrievalDone() or
> cancelTask/deferTask call missing, causing the resource to hang in this
> cases). Similar in the itemAdded|Changed|Removed methods. I could have
> fixed that easily in the time it took me to write this mail, with the
> resource in KDE's repositories ;-)
>
> regards
> Volker
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20091023/0a7ea0e5/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/
More information about the kde-pim
mailing list