Re: [Evolution-hackers] Removing libical fork, moving to new upstream?

2007-05-20 Thread JP Rosevear
On Sun, 2007-05-20 at 15:03 +0100, Ross Burton wrote:
 I discovered last week that there is an attempt to resurrect libical
 from non-maintainership, merge all of the patches from various forks,
 and start making sane releases again[1].  Are the evolution team as
 whole interested in merging their changes to libical upstream and
 depending on it to be installed when a release is made with all of the
 relevant changes?  libical isn't exactly a small library, and statically
 linking it is a waste of memory for everyone.

I vaguely recall the biggest diff being timezone handling.

 I'll happily start working on extracting the changes to EDS and pushing
 them into the new libical repository, if the Evolution team as a whole
 agrees that the fork of libical will be dropped.

I'd suggested waiting to see a pattern of stable releases before moving
externally, but getting the patches upstream would be good.

Novell, Inc.

Evolution-hackers mailing list

Re: [Evolution-hackers] Camel in evolution-data-server, a different proposal

2006-07-17 Thread JP Rosevear
On Wed, 2006-07-12 at 19:13 +0200, Philip Van Hoof wrote:
 On Wed, 2006-07-12 at 17:00 +0100, Ross Burton wrote:
  On Wed, 2006-07-12 at 17:39 +0200, Philip Van Hoof wrote:
  So you are proposing the following library packages:
  And then binary packages for the Groupwise helpers, the Exchange
  helpers, and the server binaries themselves.
 Yeah. Sounds perfect. Looks very clean.

... and fragments the platform.

 At this moment, all those fall under the name of evolution comma data
 comma server. Some of these libraries (like Camel) don't necessarily
 have anything to do with the Evolution data that is being managed by
 the data server of Evolution.

They have a lot to do with it.  iMip for calendaring for example (really
you want the imip direct mail fall back to happen in e-d-s, not the

There was also an idea to tie in a unified account settings dialog so
that exchange/groupwise/jecs could be configured in a unified manner.

 The E-mails and, folder-summaries, state data and summaries of Camel are
 *not at all* being managed by Evolutions data server. It's simply
 totally unrelated to the Evolutions data server. It looks like even some
 Novell employees don't know that, probably cause it's being marketed as
 one package.

There were plans to look at this.  In fact I discussed such a scenario
with Jeff last week.  Speed was always a major concern however, but
something like the disk summary branch might alleviate this.

 The ideal situation would be that most of these components would be
 reusable by application developers that don't have to use the Evolution
 data server at all. 
 Why glue it?

I think you're only real example is camel, which shares code with the other 
pieces anyhow.

Novell, Inc.

Evolution-hackers mailing list

Re: [Evolution-hackers] Spam attack on

2005-12-19 Thread JP Rosevear
On Mon, 2005-12-19 at 14:58 +, Tor Lillqvist wrote:
 Check out the Recent Changes page... Lots of pages have been filled with
 spam. Apparently only pages that were empty until now, though?

Same thing happened to the beagle wiki last week. Joe added Captcha
( support there to prevent further

Novell, Inc.

Evolution-hackers mailing list