Re: [Evolution-hackers] Evo and Kolab2 - a fresh attempt
Hi Michael, On Wednesday 26 May 2010 at 12:18:04 Michael Meeks wrote: Hi Christian, [...] It'd be better really to develop vs. master - from a support, testing, future-proofing, and ease-of-use perspective. Presumably it is possible to get you commit access to the repository so you can develop in the repository [ when some code has been reviewed ] - it sucks to be stuck out on a limb somewhere. We'd surely like to commit to the Evo repo. We're in the plannings still, but it is a request from our customer that our results be made public under GPLv2, and if possible, be accessible via the upstream project repo. We have some skeleton code which mainly serves to explore the wonders of Evolution right now and which we will turn into production code at some point. We will be working on the code with - as per present plans - five active developers. We're using our own Git repo for now, but it would be good for us to know that you people are willing to host us later on (that is to satisfy our funder's requirement). We'll develop our Plugin in a way that it will be a standalone one, just the way evolution-mapi is. Presumably, we will name it evolution-kolab. Shouldn't be too hard to transfer our own Git repo to your site. Is that okay with you? Anyhow - exciting to see this get underway; hopefully it can also be used as part of the Windows build - as a neat extra :-) We'll try to be as portable as possible, but our main target is Linux for now. Using GLib and friends wherever possible should prevent us from being totally Linux-specific, though. :-) Best regards, Christian PS: @Michael: sorry for the double posting, this should have gone to the list right away. -- kernel concepts GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48Fax: +49-271-771091-19 D-57072 Siegen 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
Re: [Evolution-hackers] Evo and Kolab2 - a fresh attempt
Hi there, while the project setup process is going on, I've had a look again at suitable testframeworks. Unfortunately, many unit test frameworks for the C language appear to be abandoned. On Wednesday 26 May 2010 at 12:18:04 you wrote: Hi Christian, On Wed, 2010-05-26 at 11:15 +0200, Christian Hilberg wrote: 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. I think the consensus from 10k feet is something like: any unit tests are good ! wow, you have unit tests ? cool ! :-) so it is unlikely that anyone is going to come and gripe about your unit testing framework per-se; of course people moan about new dependencies - so re-using the gtestutils.[ch] would be good if it's easy, and of course most preferably hooking it all up to 'make check' is best, as Matthew said. Using the GLib framework for testing seemed to be a natural choice, until I dug through the mail archives and found that it (a) is neither nice to set up for projects outside GLib/GTK istelf [1] (latest information I found on the issue dates back from 2008) (b) nor is it well-documented and finally (c) does not seem to be in wide use outside GTK and GLib itself. Other testframeworks I've checked (like CUnit, cUnit, RCunit, CuTest, Embedded Unit) did not receive project updates since 2006 (some since 2003), so I assume they're dead. Setting aside commercial frameworks, which are no option unless they're explicitly FLOSSed, I'm left with Unity[2], Cutter[3] and Check[4]. Cutter depends on GLib = 2.16, so I assume it uses the GLib testing framework internally and I found references to it in some GTK/GLib context. What's more, Cutter has support for GLib types (just read in the docs, no practical experience as yet), which would be helpful in our case. Check seems to be in wider usage. It fork()s a new process for each unit test it runs, which seems to be a good thing to do to protect the framework's address space from runaway test cases, unless you're so much restricted (as in some embedded environments), that you cannot fork() - but there is no point in running E-D-S in such an environment, anyway. Unity (also) targets embedded contexts and the Sourceforge project is alive (latest release 2009-12-07, current checkins to the SF repo). There does not seem to be much of a documentation online. Long story short, as for now I'm down to either Cutter or Check to use. I'd like to know if you prefer one over the other, which I would like to take into account for my proposal to the other project members regarding the testframework to use. Best regards and aTdHvAaNnKcSe for any insights, Christian [1] http://www.mail-archive.com/gtk-devel-l...@gnome.org/msg07185.html [2] http://sourceforge.net/apps/trac/embunity/wiki [3] http://cutter.sourceforge.net/ [4] http://check.sourceforge.net/ -- kernel concepts GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48Fax: +49-271-771091-19 D-57072 Siegen 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
Re: [Evolution-hackers] Evo and Kolab2 - a fresh attempt
Hi, On Mon, 2010-06-07 at 17:31 +0200, Christian Hilberg wrote: Hi there, while the project setup process is going on, I've had a look again at suitable testframeworks. Unfortunately, many unit test frameworks for the C language appear to be abandoned. On Wednesday 26 May 2010 at 12:18:04 you wrote: Hi Christian, On Wed, 2010-05-26 at 11:15 +0200, Christian Hilberg wrote: 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. I think the consensus from 10k feet is something like: any unit tests are good ! wow, you have unit tests ? cool ! :-) so it is unlikely that anyone is going to come and gripe about your unit testing framework per-se; of course people moan about new dependencies - so re-using the gtestutils.[ch] would be good if it's easy, and of course most preferably hooking it all up to 'make check' is best, as Matthew said. Using the GLib framework for testing seemed to be a natural choice, until I dug through the mail archives and found that it (a) is neither nice to set up for projects outside GLib/GTK istelf [1] (latest information I found on the issue dates back from 2008) (b) nor is it well-documented and finally (c) does not seem to be in wide use outside GTK and GLib itself. I've used the GLib test framework extensively for one of my projects, libgdata[1], and it's fine to use outside of the GLib/GTK+ trees. Several GNOME projects make use of it (more than other test frameworks in my experience). The GLib test framework can fork() tests using g_test_trap_fork() and friends. Regards, Philip [1]: http://live.gnome.org/libgdata Other testframeworks I've checked (like CUnit, cUnit, RCunit, CuTest, Embedded Unit) did not receive project updates since 2006 (some since 2003), so I assume they're dead. Setting aside commercial frameworks, which are no option unless they're explicitly FLOSSed, I'm left with Unity[2], Cutter[3] and Check[4]. Cutter depends on GLib = 2.16, so I assume it uses the GLib testing framework internally and I found references to it in some GTK/GLib context. What's more, Cutter has support for GLib types (just read in the docs, no practical experience as yet), which would be helpful in our case. Check seems to be in wider usage. It fork()s a new process for each unit test it runs, which seems to be a good thing to do to protect the framework's address space from runaway test cases, unless you're so much restricted (as in some embedded environments), that you cannot fork() - but there is no point in running E-D-S in such an environment, anyway. Unity (also) targets embedded contexts and the Sourceforge project is alive (latest release 2009-12-07, current checkins to the SF repo). There does not seem to be much of a documentation online. Long story short, as for now I'm down to either Cutter or Check to use. I'd like to know if you prefer one over the other, which I would like to take into account for my proposal to the other project members regarding the testframework to use. Best regards and aTdHvAaNnKcSe for any insights, Christian [1] http://www.mail-archive.com/gtk-devel-l...@gnome.org/msg07185.html [2] http://sourceforge.net/apps/trac/embunity/wiki [3] http://cutter.sourceforge.net/ [4] http://check.sourceforge.net/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers 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
Re: [Evolution-hackers] Evo and Kolab2 - a fresh attempt
On Wed, 2010-05-26 at 11:18 +0100, Michael Meeks wrote: Hi Christian, On Wed, 2010-05-26 at 11:15 +0200, Christian Hilberg wrote: This sounds pretty cool and would be a welcome addition to the Evolution suite. Agreed. 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. I think the consensus from 10k feet is something like: any unit tests are good ! wow, you have unit tests ? cool ! :-) so it is unlikely that anyone is going to come and gripe about your unit testing framework per-se; of course people moan about new dependencies - so re-using the gtestutils.[ch] would be good if it's easy, and of course most preferably hooking it all up to 'make check' is best, as Matthew said. 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... .. 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. Sure - the question is: what is your distro target, and timeframe to ship ? are you going for RHEL / SLED / Ubuntu LTS ? or more community focused distros ? AFAICS the latest enterprise desktops current in late spring will have the underlying O/S deps necessary (GNOME 2.28) to build run the code as of now. Matthew / Chen - we have a general policy of not requiring the latest greatest platform until the next cycle right ? ;-) AFAICS gtk+ minimum version has been bumped and we had some reasons for that which could not recollect atm. Matt should be able to provide more information there.. We had been thinking of an option of using the latest stable evolution in enterprise releases once 3.0 is released, by installing the selected platform libraries which evolution requires in a different prefix so that other apps not affected by them. As such, it is entirely possible that if you want to ship and support a product you will need to compile your own evolution, and e-d-s to ship them [ hopefully the e-d-s calendar / contacts pieces that are used more widely in the OS will still stay ABI stable ;-) ]. There will be no breakages there, though there might be some apis added.. - Chenthill. 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. It'd be better really to develop vs. master - from a support, testing, future-proofing, and ease-of-use perspective. Presumably it is possible to get you commit access to the repository so you can develop in the repository [ when some code has been reviewed ] - it sucks to be stuck out on a limb somewhere. Anyhow - exciting to see this get underway; hopefully it can also be used as part of the Windows build - as a neat extra :-) ATB, Michael. ___ 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] 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
