Re: [Evolution-hackers] Merging the collaboration providers in a single package

[Suman Manjunath <manjunath suman gmail com>]

On Tue, Oct 19, 2010 at 04:31, chen <pchenthill novell com> 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 camel localhost localdomain>, Matthew Barnes
>> <mbarnes redhat com> 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 evolution-mapi
>> > > into a single package. Other collaboration providers like
>> > > evolution-groupwise and evolution-kolab (yet to be upstreamed) will
>> > > remain as separate packages.
>> >
>> > If we -have- to glob providers together I would prefer the alternate
>> > solution: merge all the Exchange providers into one git module, break
>> > GroupWise out from E-D-S into it's own git module, and leave the rest
>> > alone.
>> >
>> > This is not unlike the recent gnome-games debate on desktop-devel-list,
>> > except that we already have shared libraries for the common parts with
>> > fairly stable APIs (libebook, libecal, etc.).
>> >
>> > Jon's comments on the gnome-games issue reflect my own for this one:
>> > http://mail.gnome.org/archives/desktop-devel-list/2010-October/msg00049.html
> The control/ownership of the code can be made clear using provider-level
> maintainer-ship (like groupwise, exchange, kolab2 maintainers etc.)
> inside a single package. Of-course package is one, but with independent
> sub-modules and owners.
>
> Is there any other disadvantage or point of concern ?

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)?

b) If we put all the providers together, and this is from what I've
seen happening, there is this tendency for code to get duplicated.
Along with good designs, sometimes bad designs also get duplicated.

>> I prefer not to have every provider in its own module.  If we make changes in the baseclass, it will be ignored and won't go into unmaintained providers. More providers translates to more work for packagers downstream and also during the release time for maintainers as well, with not much benefits.

If a module has an owner, how is it unmaintained?

As a packager, if we do glob the modules together, the first thing
that would happen is a split-up of the built files into their own
sub-packages in the spec. How is this any different from having two
separate packages?

>> Just my 2 cents.
> I agree. I would not term as un-maintained providers. If they are really
> un-maintained, which means many bugs exist and people are not able to
> use it, it has to be pruned at some point.
>
> But certainly I see advantages to have the providers in a single package
> which would help us adapt to the API changes well, translations could be
> shared, packagers can look for updates for one package and maintainers
> would have less burden in releasing many packages.

Turning it around the other way, if a change in the globbed package
means nothing to the provider I'm using or interested in, what's in it
for me to update the package? :-)

If a module is maintained, the API changes will eventually get there.
Besides, you shouldn't be changing the base API that often anyway ;-)

-Suman