On Wed, 2004-08-25 at 10:57 +0800, Not Zed wrote:
* Fewer packages to maintain.
I would add:
* a single package for accessing all evolution data.
You mean, apart from libsoup, gnome and gtk+ libs, etc :)
yeah :) that's why it could be a good reason: to avoid increasing
On Wed, 2004-08-25 at 16:34 +0200, Rodrigo Moya wrote:
On Wed, 2004-08-25 at 10:57 +0800, Not Zed wrote:
* Fewer packages to maintain.
I would add:
* a single package for accessing all evolution data.
You mean, apart from libsoup, gnome and gtk+ libs, etc :)
yeah :)
* Fewer packages to maintain.
I would add:
* a single package for accessing all evolution data.
I really favour the camel in e-d-s option, because it makes e-d-s
the one-stop-shop for accessing Evolution data. I think that is
actually a convenience for developers, not a hindrance.
Well, I
This is a mail i sent internally before, JP asked me to bounce it out, others might have contributions to make here.
There are some compelling reasons for putting camel in eds, but also several for not doing it.
in:
Camel depends on some minor things in e-util. E-util will almost
Hi,
Yes, i think it would be more meaningful to split out camel from evolution [ since evo is more of a shell anyway ]. The points listed down below for having camel as a separate entity definately out-weigh the reasons for it to be part of e-d-s. Moreover, if e-d-s moves to the mode of
On Tue, 2004-08-24 at 20:07 +0800, Not Zed wrote:
This is a mail i sent internally before, JP asked me to bounce it out,
others might have contributions to make here.
There are some compelling reasons for putting camel in eds, but also
several for not doing it.
in:
* Camel
On Tue, 2004-08-24 at 18:55 +0530, Sarfraaz Ahmed wrote:
Hi,
Yes, i think it would be more meaningful to split out camel from
evolution [ since evo is more of a shell anyway ]. The points listed
down below for having camel as a separate entity definately out-weigh
the reasons for it to be
