Re: [Evolution-hackers] Evo and Kolab2 - a fresh attempt

2010-07-07 Thread Christian Hilberg
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

2010-06-07 Thread Christian Hilberg
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

2010-06-07 Thread Philip Withnall
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

2010-05-26 Thread chen
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