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

[Michael Meeks <michael meeks novell com>]

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 ? ;-)

	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 ;-) ].

>  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.

-- 
 michael meeks novell com  <><, Pseudo Engineer, itinerant idiot