[Evolution-hackers] Evo and Kolab2 - a fresh attempt
Hi everyone. Presently, my company and it's associates are in the process of setting up an open source project to (among other things) integrate Evolution with the Kolab2 groupware server. The goal is to support as much of Evo's and Kolab's functionality as possible. We have searched the web for information on similar projects and so far found all of them in some kind of stasis or to be abandoned. In case we've overlooked something and there is active development going on somewhere in this regard, we'd be grateful to receive a pointer to the respective project(s). We aim to create a project which has good chances to go upstream. Plans are to implement an E-D-S backend for Evo like the one for GroupWise. At the moment I'm tasked with collecting information on how to do it "the Evolution way" in order to improve the project's chances to go upstream. 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. Connecting Evo and Kolab2 will most likely involve rather heavy use of LibCamel infrastructure. Which Evolution version we will concentrate on is not yet fixed, but reading the mailing list archives I found there is a lot of change due to happen within this library. Although we might settle upon the current stable Evolution (or even the Evolution version of some specific stable Linux version, for a start), we would like to keep in mind that the Camel API will change and internals like the type system will undergo some major transitions. We would therefore like to avoid to writing code which will be hard to port to newer Evo versions. Unfortunately, there does not seem to be a "new developer's guide" which lists the pitfalls to avoid when writing backend code for current stable 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. Questions galore - any helpful input will be kindly appreciated. :) Best regards, Christian Hilberg -- kernel concepts GbRTel: +49-271-771091-12 Sieghuetter Hauptweg 48Fax: +49-271-771091-19 D-57072 Siegen Mob: +49-176-21024535 http://www.kernelconcepts.de/ signature.asc Description: This is a digitally signed message part. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Heads Up: Merging express2 branch
Just a heads up that I'm in the process of merging the 'express2' git branch into master today, so the next unstable release will debut some impressive new features in "express" mode (evolution --express). But also be on the lookout for regressions in either normal or express mode in the coming days and fire off bug reports if you spot anything. Matthew Barnes ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evo and Kolab2 - a fresh attempt
Hi Christian, This sounds pretty cool and would be a welcome addition to the Evolution suite. On Tue, 2010-05-25 at 19:29 +0200, Christian Hilberg wrote: > We have searched the web for information on similar projects and so far > found all of them in some kind of stasis or to be abandoned. In case we've > overlooked something and there is active development going on somewhere in > this regard, we'd be grateful to receive a pointer to the respective > project(s). I know of no other active Evolution/Kolab2 project at the moment. > We aim to create a project which has good chances to go upstream. Plans are > to implement an E-D-S backend for Evo like the one for GroupWise. At the > moment I'm tasked with collecting information on how to do it "the Evolution > way" in order to improve the project's chances to go upstream. 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). > 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. 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. > Connecting Evo and Kolab2 will most likely involve rather heavy use of > LibCamel infrastructure. Which Evolution version we will concentrate on is > not > yet fixed, but reading the mailing list archives I found there is a lot of > change due to happen within this library. Although we might settle upon the > current stable Evolution (or even the Evolution version of some specific > stable Linux version, for a start), we would like to keep in mind that the > Camel API will change and internals like the type system will undergo some > major transitions. We would therefore like to avoid to writing code which > will > be hard to port to newer Evo versions. Unfortunately, there does not seem to > be a "new developer's guide" which lists the pitfalls to avoid when writing > backend code for current stable 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. 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. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Heads Up: Merging express2 branch
On Tue, 2010-05-25 at 15:26 -0400, Reid Thompson wrote: > is there a short explanation of what express is somewhere? It's an attempt to simplify and rewire Evolution's user interface to be more suitable for small screen netbooks -- particularly devices running MeeGo. It's an alternate mode invoked through a command-line switch, but we think many of the ideas being prototyped will likely end up bleeding into the main Evolution interface in one form or another. For more details and status, see: http://live.gnome.org/Evolution/Art ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
