Hi Matthew, On Tuesday, 25 May 2010, you wrote: > Hi Christian, > This sounds pretty cool and would be a welcome addition to the Evolution > suite. Good. :) > On Tue, 2010-05-25 at 19:29 +0200, Christian Hilberg wrote: > > [...] > I know of no other active Evolution/Kolab2 project at the moment. Well, then we're good to go. > [...] > We prefer backends for groupware servers to be packaged as a standalone > extension module for Evolution. See for example evolution-exchange and > evolution-mapi (and I believe the GroupWise backends will soon be split > off similarly). Thanks for the hint. We'll try it that way then. > > QA is one of the topics which will be stressed, so I was checking how > > unit testing is done within Evolution. Skimming through the sources of Evo > > 2.28.3, I found that there does not seem to be the "one specific way" of > > doing testing, hence I would be interested in getting to know whether > > there is a preferred way of doing (unit) testing. > We are woefully lacking an actively maintained and comprehensive unit > test suite and I don't think the project has yet matured to the point > where we even -have- a unit testing preference. I'd recommend looking > to the broader GNOME community for best practices. We'll check that out with other Gnome projects. It may take some more research on the project itself before we know how to actually accomplish the testing stuff. My thoughts atm tend towards cunit/expect and/or the GLib testing framework. We'll check which method will impose the least impact in respect to dependencies. Let's see whether there is some gnomish/gtk'ish/GLib'ish way of doing testing which will be fitting for an Evo extension. > Mainly I think you want to integrate the tests into your autotools > framework (assuming that's what you're using) so the tests are executed > by running "make check" or "make distcheck". In addition, GLib offers > some basic utilities for constructing test fixtures, though I'm not sure > to what extent that API has really caught on yet. autotools, 'make check' and friends will be the road to take, as far as I can see right now. We'll take a closer look at the GLib testing framework to see how much usable it is already. > > Connecting Evo and Kolab2 will most likely involve rather heavy use of > > LibCamel infrastructure. Which Evolution version we will concentrate on > [...] > > versions of Evo which should later be ported painlessly to newer > > versions of Evo. It would be great to be pointed into the right > > directions here. > I'd strongly recommend targeting at least version 2.30, and if you're > that heavy on Camel and can withstand a little API churn, 2.31 would be > best so that you're using GObject from the get go. Version 2.30 of both > Evolution and E-D-S was such a significant step forward from previous > releases that I've come to regard it as a generation gap. Targeting a > release from an earlier generation will likely mean more pain down the > road when you finally have to cross that gap. Hopefully, it will be possible for us to do it that way. We have just begun our evaluation process, so lets see. Using the GLib'ified Evo code right from the start would be wise. Anyway, we'll have to check whether we can afford using Evo 2.30 / 2.31 as a code basis for our project... > It's true that libcamel's backward compatibility guarantees have been > temporarily withdrawn until its API is sufficiently modernized. The API > changes for 2.31 should taper off within the next month or so, then pick > up again once libgio gains support for transport layer security. > I'm guessing the Camel upgrades will be mostly complete by Evolution 3.2 > next spring (assuming TLS support lands on schedule), and thereafter API > and ABI stability will be restored. Phew, that's quite some time down the road. Our project is scheduled to show usable results (i.e. installable packages which work as expected) within this year. That means we might have to use a current stable version of Evo for now. OTOH, it is also no fun to raise a project which is obsolete-by-design. We'll have to meditate on that. Thanks for taking time to give us some useful hints! We'll be around. Best regards, Christian -- kernel concepts GbR Tel: +49-271-771091-12 Sieghuetter Hauptweg 48 Fax: +49-271-771091-19 D-57072 Siegen Mob: +49-176-21024535 http://www.kernelconcepts.de/
Attachment:
signature.asc
Description: This is a digitally signed message part.