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

[chen <pchenthill novell com>]

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