On Wed, 2010-05-26 at 11:18 +0100, Michael Meeks wrote:
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
We'll check that out with other Gnome projects. It may take some more
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
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
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
usable results (i.e. installable packages which work as expected) within
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
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
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.
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 :-)
evolution-hackers mailing list
To change your list options or unsubscribe, visit ...