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

["Sankar P" <psankar novell com>]

> 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 how it works in other projects, say Kernel. 

The linux kernel has dozens of file systems. Most of the distros are interested in a few of the filesystems only. But the reason why all are kept in the tree is because the changes will be updated in all the filesystems. It is easier to implement new build policy changes as well, if everything is in one place. 


 
> 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.
>

Yes. Absolutley.  In the same way, once a bad design is identified in one module and fixed, there is more chance of it getting fixed in rest of the providers as well, if it stays in the same tree. 
 
>>> 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?
> 

The maintainer can go on a leave or focus on some other urgent new activity etc. (Say EWS).  But I agree with Chen that "Unmaintained" is a poor word selection. 

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

<Packager Hat>

Why ? We wont. We will just get one tarball update when released and build that with whatever configure options that suits our distro.  We won't attempt to divide further. 

Like for instance, for kernel, we have only: kernel-pae/x86_64.rpm and no kernel-fs-ext3.rpm, kernel-fs-btrfs.rpm etc.  All filesystems are inside the kernel.rpm

</Packager Hat>

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

None. Agreed.  

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

Agreed.  Ideally ;-)

Sankar