Re: Camel in evolution-data-server, a different proposal

Philip Van Hoof <[email protected]>
Newsgroups gmane.comp.gnome.evolution.devel
Message-ID <[email protected]>
On Thu, 2006-07-13 at 11:35 +0100, Ross Burton wrote:
> On Thu, 2006-07-13 at 12:25 +0200, Philip Van Hoof wrote:

> > I wasn't (am no longer) proposing to move "camel/" out of e-d-s. I was
> > proposing to put a configure.ac file in its directory. Moving Camel out
> > of evolution-data-server/ is not the scope nor point of this thread.
> 
> For what purpose?  Camel depends on libedataserver.

Being a developer, I can probably fix that chicken and egg problem in a
few hacking evenings.

> So you've found a problem with the Red Hat packaging, in that it treats
> all of EDS a single library.  File a bug with Red Hat, and notice that
> Debian, Maemo, and OpenEmbedded (at least) already have split EDS
> packages.

I very much applaud what OpenEmbedded, Maemo, OpenedHand and Debian did
in terms of packaging. It's indeed the right way.

> In the scheme of things this is a very minor issue which effects very
> few people.  I'd prefer to see effort spent on fixing bugs and memory
> leaks.

I agree it's a minor issue. But things can happen in parallel. This is
why people developed round robin algorithms in schedulers :). Else the
minor ones or very-low-priority ones never get any attention from the
processing unit (because the large ones eat up exactly 100% of the
processing units time).

However, I do agree that we are putting to much of a discussion/fight on
it. It should probably simply be a patch and a get-it-over-with commit.


ps. Is there a beach at the Boston Summit? Maybe we can do a beach-fight
about it? :-) (ps. I'm not yet sure if I will attent the summit).

-- 
Philip Van Hoof, software developer at x-tend 
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
work: vanhoof at x-tend dot be 
http://www.pvanhoof.be - http://www.x-tend.be
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.