Re: [Evolution-hackers] evolution-kolab: Lifting the veil

["Sankar P" <psankar novell com>]

>>> On 7/9/2010 at 09:44 PM, in message <1278692045 6831 33 camel linux-e1q4 site>,
chen <pchenthill novell com> wrote: 
> On Thu, 2010-07-08 at 13:01 -0400, Matthew Barnes wrote:
> > On Thu, 2010-07-08 at 16:01 +0100, Michael Meeks wrote:
> > > > If Evolution staff will be willing to host our project sources within
> > > > Evo git repo, we'll happily transfer our stuff there as soon as we
> > > > have a first preview ready.
> > > 
> > > 	Perhaps something to dicuss on #evolution (irc.gimp.net) - but it'd be
> > > great to have you working in the same git repo IMHO [ not that it's my
> > > decision of course - I defer to Matthew/Chen etc. ;-]
> > 
> > 
> > Certainly aim for hosting your project on git.gnome.org, but I'd still
> > prefer it be split into a separate evolution-kolab repository similar to
> > evolution-exchange, evolution-mapi, and soon evolution-groupwise (I'm
> > told).  It just keeps things more modular and it keeps us honest: our
> > public APIs -have- to be complete since external projects don't have
> > access to private in-tree APIs.  The separation is not meant to be a
> > barrier between you and us, just an implementation detail.
> While thinking about this, I just got a thought of why not a,
> evolution-collab-backends package which can hold all the eds
> collborative backends (that provides mail+calendar+address-book) such as
> mapi, exchange, groupwise with sufficient configuration options to
> choose what to compile ? This would help in making the api changes to
> all backends and keep external backends connected. 
> 
> I support maintaining the backend code in a separate package though. Its
> easier to provide updates to the backends if its not part of eds
> at-least with some distros (at-least with suse as I use it).
>


More modules translate to more problems trying to build things. Oh I need to git clone another 10 modules. In my opinion, we should just follow linux kernel filesystems style (all under one tree). There can be any number of backends, but we can use sane config options to build only interested backends (for instance someone working on RHT may not bother about GW etc.) But for someone who wants to build evo with all backends, it is just one 'git clone' that he needs to do. 

Also, during release time, more modules contribute to more work for the maintainer(s).  Changes made in core may not reflect in some low priority backends, if they are kept out of the tree. (oh that out-of-tree Scalix backend is still using flat-file-summary-APIs-oh-wait-lets-ignore-it etc. types)

However,  I am a little out of touch with the things and so I trust Chen/Matthew 's decisions as they know the current state. Just my 2 cents. 

Sankar
 
> - Chenthill.
> > 
> > The process for obtaining a gnome.org account is here:
> > 
> >         http://live.gnome.org/NewAccounts 
> > 
> > Each of your developers should apply for their own account, but I would
> > suggest waiting to do this until after you have a working public beta,
> > as you'll have more credibility to the gnome.org admins then (which is
> > not us!).
> > 
> > Once you have your gnome.org accounts, you can clone your git repository
> > on git.gnome.org by following the procedure here:
> > 
> >         http://live.gnome.org/Git/NewRepository 
> > 
> > Hope this helps.
> > 
> > 
> > _______________________________________________
> > 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 
>