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

2010-10-19 Thread chen
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
 mbar...@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 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.  
 
 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.


- Chenthill.
 
 Sankar
 
 ___
 evolution-hackers mailing list
 evolution-hackers@gnome.org
 To change your list options or unsubscribe, visit ...
 http://mail.gnome.org/mailman/listinfo/evolution-hackers



___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


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

2010-10-19 Thread Suman Manjunath
On Tue, Oct 19, 2010 at 04:31, chen pchenth...@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.ca...@localhost.localdomain, Matthew Barnes
 mbar...@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
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


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

2010-10-19 Thread Sankar P
 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

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


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

2010-10-18 Thread Matthew Barnes
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


___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


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

2010-10-18 Thread Sankar P
 On 10/18/2010 at 07:01 PM, in message
1287408711.3126.11.ca...@localhost.localdomain, Matthew Barnes
mbar...@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 
 
 

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.  

Just my 2 cents. 

Sankar

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers