Re: [Evolution] MAPI exchange bits




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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]