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


Re: [Evolution-hackers] GTK+ requirements (was: Evo and Kolab2 - a fresh attempt)

2010-05-26 Thread Matthew Barnes
On Wed, 2010-05-26 at 17:57 +0530, chen wrote:
 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 have a policy of only requiring the latest -stable- platform so that
you can always build, for example, Evolution 2.31 on GNOME 2.30.

The GTK+ minimum requirement bumps as of late allow us to use new
accessor functions for sealed widget members.  We're in an awkward
situation right now where not only are -we- trying to prepare for GTK+
version 3, but so is GTK+ itself.  To that end, we're trying to keep up
with GTK+ developments as much as the above policy will allow.  


___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers