Re: [Evolution] MAPI exchange bits

[Srinivasa Ragavan <sragavan novell com>]

On Fri, 2007-11-30 at 11:41 -0800, C.J. Adams-Collier wrote:
> 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? 

You need to gain the maintainers confidence to commit with out
review ;-)

Even for most of our patches, we do internal review. Lot of time, even
my patches I get them reviewed by someone to be more confident. The
review process shouldn't stop you really :)

>         > > 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 now nothing automated AFAIK. We have our test team who do their
part.

>         > > 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. 
Im just not sure of the OBS support for RHEL3. 

-Srini.
>  
>         -Srini.
>
> Cheers,
>
> C.J.
>
> -- 
> moo.