>>> On 7/9/2010 at 09:44 PM, in message 
>>> <1278692045.6831.33.ca...@linux-e1q4.site>,
chen <pchenth...@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 
> 

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

Reply via email to