> I somewhat agree with Matthew on this one. If we glob all the
> providers together:
>
> a) Distro A doesn't want to support Provider X. You'd say we'll have a
> compiler option to not compile X. Why does Distro A even need the
> sources for X (and eventually ship it too)?
>
For the same reason
On Tue, Oct 19, 2010 at 04:31, chen wrote:
> On Mon, 2010-10-18 at 09:21 -0600, Sankar P wrote:
>> >>> On 10/18/2010 at 07:01 PM, in message
>> <1287408711.3126.11.ca...@localhost.localdomain>, Matthew Barnes
>> wrote:
>> > On Mon, 2010-10-18 at 12:10 +0530, chen wrote:
>> > > The other solution
On Mon, 2010-10-18 at 09:21 -0600, Sankar P wrote:
> >>> On 10/18/2010 at 07:01 PM, in message
> <1287408711.3126.11.ca...@localhost.localdomain>, Matthew Barnes
> wrote:
> > On Mon, 2010-10-18 at 12:10 +0530, chen wrote:
> > > The other solution was to maintain all exchange providers in a single
>>> On 10/18/2010 at 07:01 PM, in message
<1287408711.3126.11.ca...@localhost.localdomain>, Matthew Barnes
wrote:
> On Mon, 2010-10-18 at 12:10 +0530, chen wrote:
> > The other solution was to maintain all exchange providers in a single
> > package, merging evolution-exchange, evolution-ews and e
On Mon, 2010-10-18 at 12:10 +0530, chen wrote:
> The other solution was to maintain all exchange providers in a single
> package, merging evolution-exchange, evolution-ews and evolution-mapi
> into a single package. Other collaboration providers like
> evolution-groupwise and evolution-kolab (yet t
Hi,
We had discussed about merging the collaborative providers such as
evolution-exchange, evolution-mapi, groupwise, kolab and evolution-ews
(on development) into a single package in previous community meeting.
There are certain advantages and some concern areas in it, let me
summarize them on w
