Re: [Evolution] MAPI exchange bits

["C.J. Adams-Collier" <cjcollier gmail com>]

On Nov 29, 2007 8:07 PM, Srinivasa Ragavan <sragavan novell com> wrote:

On Thu, 2007-11-29 at 08:37 -0800, C.J. Adams-Collier wrote:
> On Thu, 2007-11-29 at 15:22 +0530, Srinivasa Ragavan wrote:
> > Hey,
> >
> > On Wed, 2007-11-28 at 12:29 -0800, C.J. Adams-Collier wrote:
> > > What is the policy regarding committing patches to this branch?
> > We commit every few lines on our disk to the branch :)
>
> Does "we" include me? :)

It is all open-sourced. You are free to help us with patches :)

Alrighty, but the real question is: would you prefer to review the patches first, or would you mind me committing sans review, since this is a branch and not the trunk?

> > Only after that I can commit the code to the
> > Evolution trunk.
>
> Is this keeping you from committing to the EXCHANGE_MAPI_BRANCH branch?
> It sounds like it's not.  How often are changes from trunk integrated
> back to the MAPI branch?

>
I really don't want to push any code that has licensing issues into the
main tarball and developing in a branch and merging later would be fine,
since it helps to keep the stability of the trunk. Changes from the
trunk aren't integrated to the branch. Later some point, I would merge
the branch to trunk. It should be pretty simple IMO

Okay, so long as the GNOME Foundation doesn't mind having code with "licensing issues" in their repository (be it in a branch or the trunk).

I'll look into integrating changes from the trunk back into EXCHANGE_MAPI_BRANCH as a first project.

jhbuild completed the build of evolution (and dependencies) from trunk yesterday, and I began the process of gathering dependencies for the MAPI branch.  I don't think I have the ./configure args set up the way I want just yet, but I'm getting close...

Debian's libcupsys2-dev provides headers and libs on which evolution-data-servers depends.  However, libcupsys2-dev claims dependence on libkrb5-dev where I've been using heimdal-dev.  I sent a patch to them to change from libkrb5-dev to libkrb5-dev | heimdal-dev and built the patched .deb myself.  This allows me to use mostly stock .deb packages to meet build requirements and still provide kerberos5 libs & headers for my preferred implementation.
 

Evolution/
       configure.in
       plugins/exchange-mapi

EDS/
       configure.in
       addressbook/backend/mapi
       calendar/backend/mapi
       camel/providers/mapi
       servers/mapi

These are the directories and just the configure.in and Makefile.am
would be the real merge work.

Okay.  I'll keep this in mind.
 

I could have made this a conditional
compilation in trunk, but still I want to do the initial things in a
branch and merge.

This is a wise policy :)  Conditionals should be avoided.  They cause "edge cases" which are difficult to exercise thoroughly.

Speaking of testing, how do I run the regression suite?  make check?

> > Till then I'm hoping is to have weekly/biweekly
> > opensuse buildservice packages for SUSE/Fedora/Debian (What ever OBS
> > supports) for testing and help us back. If any one wants to help us in
> > getting the OBS ready, your help is welcome.
>
> Hmmm... What's OBS, and does it build RHEL3 packages, perchance?

OBS - OpenSUSE Build Service. (RHEL3? I really donno. It sure builds for
fedora/OpenSUSE/debian). So it may...

Alrighty.  The supported corporate dev desktops are all RHEL3, so I'm sure the devs here would appreciate an .rpm they can install with minimal effort.
 

-Srini.

Cheers,

C.J.

-- 
moo.